Grupo de Trabalho de Voz sobre IP (GT-VOIP) Ambiente para Simular Ligações Telefônicas IP no Backbone RNP2

Transcrição

1 Grupo de Trabalho de Voz sobre IP (GT-VOIP) Ambiente para Simular Ligações Telefônicas IP no Backbone RNP2 Cesar A. Marcondes, Paulo H. A. Rodrigues, Fabio David Núcleo de Computação Eletrônica (NCE) Universidade Federal do Rio de Janeiro (UFRJ) {cesarmarcondes, aguiar, I - INTRODUÇÃO O objetivo é descrever a infra-estrutura de coleta e monitoramento da qualidade de ligações de voz sobre IP da fase 0 do piloto VOIP. Neste sentido, desenvolvemos um ambiente experimental de geração e recepção de tráfego de telefonia IP, coletando e armazenando os dados do comportamento destes fluxos multimídia enviados via protocolo RTP (Real Time Protocol) [1] A finalidade é usar estas medidas para se ter uma idéia da capacidade da RNP2 em prover serviços de telefonia IP sem o uso de políticas específicas de qualidade de serviço, usando apenas o excedente de banda passante do seu backbone. E posteriormente, verificar a melhoria numa eventual migração do backbone para suporte a serviços diferenciados. A análise da qualidade desta coleta será baseada nos parâmetros obtidos pelo protocolo complementar do RTP, o RTCP (Real Time Control Protocol). Com ele, é possível calcular algumas medidas de interesse como perda de pacotes e atrasos, de modo a obtermos subsídios para sugerir mudanças na RNP2, de modo a termos um melhor desempenho dos pacotes contendo voz dentro desta rede. O presente relatório está dividido em 8 seções. Na seção 2 é feita uma breve revisão do protocolo RTP e de como é realizado o cálculo das medidas de interesse pelo RTCP. Na seção 3 é apresentada a metodologia de captura em testes reais, usando programas de código fonte aberto de telefonia IP, destacando os métodos de formação das variáveis do RTCP dos programas usados, bem como a estrutura dos arquivos de estatísticas gerados por eles. Na seção 4 é descrito o roteiro para a consolidação dos arquivos de logs de modo a termos uma maior capacidade de visualização neste processo, sem perder as informações para avaliações mais precisas. É mostrado um ambiente de visualização gráfica, baseado na Web, dos resultados estatísticos. As conclusões do trabalho e sugestões de trabalhos futuros são apresentados na seção 5. II PROTOCOLO DE TRANSPORTE PARA APLICAÇÕES DE TEMPO REAL O Real-Time Protocol (RTP) é um protocolo que provê serviços ao transporte fim-a-fim dos dados por aplicações com restrições de tempo, como o áudio interativo de ligações telefônicas. Estes serviços providos são: identificação do tipo de carga de mídia transportada, numeração em seqüência dos pacotes, marcação de tempo e monitoramento da qualidade da sessão multimídia, usados pela aplicação, entre outros. O RTP não provê sozinho quaisquer mecanismos que garantam a entrega dos dados no tempo desejado, ou com uma qualidade de serviço diferenciada, esses requisitos devem ser obtidos pela própria camada inferior, à de rede. Nas sessões multimídia RTP, cada participante envia continuamente o áudio em pequenos trechos de 20 ms (por exemplo) encapsulados num cabeçalho RTP e por sua vez, também encapsulados em um pacote UDP. Esses pacotes de áudio então são enfileirados no destino para que possam ser tocados com a devida correspondência de tempo. Em conjunto com o RTP, fazendo o monitoramento da qualidade de serviço e outras informações sobre os participantes da sessão está o RTCP. Assim como o RTP, as mensagens do RTCP também são transportadas sob o UDP. Tendo a sua periodicidade dependendo do número de participantes na sessão. Estas mensagens de controle se distinguem do RTP pelo uso de portas UDP diferentes, tendo para uma ligação IP, um par de portas UDP adjacentes reservadas para o RTP/RTCP, sendo a porta par com valor mais baixo no contexto, usada pelo RTP, e a porta ímpar com valor mais alto, usada pelo RTCP.

2 A Tipos de Pacotes RTCP e Respectivos Cabeçalhos São definidos vários tipos de pacotes RTCP que transportam uma variedade de informações de controle como o SR ou Sender Report, usado para a transmissão e recepção de estatísticas de participantes que são fontes emissoras de áudio ativas; e o RR ou Receiver Report, para a qualidade da recepção de participantes que não são fontes emissoras. Estes dois tipos de mensagens são os mais importantes para nosso experimento. É possível concatenar múltiplos pacotes RTCP sem quaisquer separadores para formar um único pacote RTCP composto que pode ser enviado em um único pacote UDP, estes pacotes compostos devem ter pelo menos dois relatórios RTCP individuais, sendo um deles normalmente um relatório de estatísticas SR ou RR. A seguir apresentamos a figura (Fig.1) de um pacote RTCP composto, contendo dois relatórios de estatísticas: um SR e outro RR. Veremos nas próximas seções que a implementação da pilha RTP/RTCP do OpenH323, usado para gerar o tráfego, usa pacotes compostos para enviar tanto os SRs quanto os RRs. V=2 P RC payload length SSRC of sender NTP timestamp, most significant word NTP timestamp, least significant word RTP timestamp sender's packet count sender's octet count SSRC_1 (SSRC do first source) fraction lost cumulative number of packets lost A.1 Relatório do Emissor (Sender Report) extended highest sequence number received interarrival jitter last SR (LSR) delay since last SR (DLSR) Fig. 1 Exemplo de pacote RTCP Composto contendo cabeçalhos gerais (parte mais clara), SR (parte clara) e RR (parte escura) Os campos de cabeçalhos contidos em um relatório SR (oriundo de uma mesma fonte, verificado pelo SSRC Synchronization Source) dentro da mensagem RTCP são mostrados a seguir: NTP timestamp (64 bits) captura o horário local de sistema da máquina fonte, no momento do envio da mensagem SR, usando a formatação do NTP (Network Time Protocol) [3]. RTP timestamp (32 bits) corresponde ao instante de tempo abreviado (sendo normalmente múltiplo da mesma unidade da amostragem de áudio) em que os dados de áudio pertencentes ao último pacote RTP foram enviados por esta fonte. Sender s packet count (32 bits) Contador cumulativo do total de pacotes de dados RTP transmitidos pelo emissor desde o início da transmissão até o momento em que este pacote SR foi gerado. Sender s octet count (32 bits) Contado cumulativo do total de octetos de carga útil (não incluindo cabeçalhos) transmitidos nos pacotes de dados RTP pelo emissor desde o início da transmissão até este pacote SR ser gerado. A.2 Relatório do Receptor (Receiver Report) No caso das mensagens RR, cada bloco de relatório de recepção carrega estatísticas, a respeito de uma única fonte de sincronização (SSRC). Os principais campos são os seguintes: SSRC_n (32 bits) transporta o identificador da fonte a qual esta informação de recepção pertence.

3 Fraction lost (8 bits) Esta fração é definida pelo número de pacotes perdidos dividido pelo número de pacotes esperado. Cumulative number of packets lost (24 bits) O número total de pacotes de dados RTP da fonte SSRC_1 que foram perdidos desde o começo da recepção (valor cumulativo). Este número é definido pelo número de pacotes esperado menos o número de pacotes atualmente recebidos. O número de pacotes esperado é definido pelo extended highest sequence number received (próximo item), menos o número de seqüência inicial recebido. Extended highest sequence number received (32 bits) trata-se do número de pacotes esperado. O valor deste campo é dividido em dois grupos de 16 bits, os bits mais significativos apresentam o número relativo ao ciclo de seqüências, e o menos significativo representa o número de seqüência mais alto recebido em pacotes RTP recebidos. Interarrival Jitter (32 bits) esta é uma estimativa da variância estatística do tempo entre chegadas dos pacotes de dados RTP, medido em unidade de amostragem e expressado sempre como um inteiro positivo, ou seja, se o jitter for negativo, ele é apresentado com o sinal invertido. Last SR timestamp (LSR) (32 bits) Indica quando chegou o último SR. Sendo formado pelos 32 bits da parte do meio do timestamp NTP, do pacote RTCP SR mais recente da fonte SSRC_n. Se nenhum SR tiver sido recebido, o campo é zerado. Delay Since Last SR (DLSR) (32 bits) O atraso, expressado em unidades de 1/65536 segundos, entre a recepção do último pacote SR da fonte SSRC_n e o envio deste RR. Se nenhum pacote SR tiver sido recebido da fonte SSRC_1, o campo DLSR é configurado com zero. B.1 Jitter B Cálculo das Medidas de Interesse O jitter entre chegadas J é definido como: o desvio padrão da diferença D correspondente ao espaço de tempo entre um par de pacotes recebidos, comparado com os tempos estampados no par de pacotes enviado. Como mostrado na equação abaixo, isto é equivalente a diferença no tempo relativo ao transito para dois pacotes; o tempo relativo ao transito é a diferença entre um timestamp RTP de um pacote e o relógio do receptor no momento da chegada do pacote, medidos na mesma unidade (de amostragem). Logo, seja Si o timestamp RTP do pacote i, e Ri o tempo de chegada em unidades de timestamp RTP do pacote i, então para dois pacotes i e j, D pode ser expresso como: D ou ( i, j ) = ( Rj Ri ) ( Sj Si ) = ( Rj Sj ) ( Ri Si ) O jitter entre chegadas é calculado continuamente por uma equação filtrada de desvio padrão, assim quando cada pacote i for recebido da fonte SSRC_n, calcula-se esta diferença D em relação ao pacote prévio i 1 em ordem de chegada (não necessariamente em ordem de seqüência), de acordo com a fórmula: J + J= ( D( i 1, i) J ) Toda vez que um relatório de recepção RR for montado, o valor corrente deste J é amostrado. O cálculo do jitter é prescrito na RFC 1889 para permitir o monitoramento independente do perfil (áudio, vídeo, usando um ou outro codificador) e tornar válido a interpretação de relatórios vindos de diferentes implementações. O algoritmo usado em J usa um estimador ótimo com parâmetro de ganho 1/16 dando uma boa redução da taxa de ruído (pelo jitter) enquanto mantém uma taxa razoável de convergência. B.2 Tempo de Ida e Volta (Round Trip Time) Outra medida de interesse importante calculada a partir dos pacotes SR e RR é o round-trip time, ou atraso de ida e volta dos pacotes RTCP/UDP. Para calcular esta medida, são usados: o campo NTP timestamp do RTCP SR, do lado do emissor. E os campos LSR (Last Sender Report timestamp) e DSLR (Delay Synce Last Sender Report) do lado do receptor, com isso é possível verificar este tempo de ida e volta. 16

4 n r 10 Nov :33: SR (n) ntp_sec = 0x b44db705 ntp_frac = 0x ( ,125 s) DLSR (5,250 s) RR (n) dlsr = 0x ( 5,250 s) lsr = 0x b705:200 (46853,125 s) 10 Nov :33:36.5 A = b710:8000 (46864,500 s) Fig. 2 Calculando o tempo de round-trip Na figura anterior (Fig. 2), seja (r) o receptor, recebendo um relatório SR do emissor (n). A fonte SSRC_(n) computa o atraso RTT pelo envio do tempo absoluto (NTP) encapsulado em seu SR, logo depois o receptor ao montar o pacote RR, preenche o campo LSR com o valor abreviado do NTP recebido pelo SR. E também insere o tempo entre a chegada do SR do emissor e o envio deste RR pelo receptor. Enfim, quando o pacote RR chega ao emissor, ele pode calcular o round-trip time usando somente o seu relógio como parâmetro. Marcando o tempo de chegada deste pacote RR (valor A), e usando todos os outros parâmetros LSR e DLSR. Assim, o round-trip é o resultado da fórmula (A LSR DLSR). No exemplo exibido na Fig. 2, teríamos o RTT igual a: A +0xb710:8000 (46864,500 s) DLSR 0x0005:4000 ( 5,250 s) LSR 0xb705:2000 (46853,125 s) Atraso (RTT) +0x 6:2000 ( 6,125 s) Tab. 1 Calculando o round-trip a partir dos parâmetros É importante notar que os valores calculados nos respectivos campos estão na formatação NTP abreviada (coluna do meio). Logo é preciso realizar a conversão para o tempo em segundos (mostrado na coluna da direita da tabela anterior - Tab. 1). B.3 Outras medidas de Interesse (Perda Acumulada, Perda Instantânea, Fração de Perda, Vazão) Entre as outras medidas que podem ser obtidas, temos o parâmetro sobre a perda de pacotes que pode ser observada sob várias perspectivas. Como um valor acumulado ao longo da ligação por exemplo, ou verificada instantâneamente pelo número de pacotes perdidos em um certo intervalo de tempo. Para tanto, com base no número de pacotes perdidos entre dois relatórios de recepção consecutivos podemos determinar o valor instantâneo. A razão entre a perda instantânea de pacotes em um período, pelos pacotes esperados é igual a fração de pacotes perdidos sob o intervalo. Esta razão deve ser igual ao campo fraction lost (pacote RR) se os dois relatórios forem consecutivos, de outro modo não. A taxa de perda por segundo pode ser obtida pela divisão entre a fração de perda pela diferença dos timestamps NTP, expressa em segundos. O número de pacotes esperado também pode ser usado para julgar a validade estatística de quaisquer estimativas de perda, por exemplo 1 entre 5 pacotes perdidos tem menor relevancia do 200 entre De informações do emissor, pode-se calcular também a taxa média de dados úteis e a taxa média de pacotes sob um intervalo, sem ao menos estar recebendo os dados. Tomando a razão dos dois temos a média do tamanho da carga útil do pacote. Se puder ser assumido que a perda de pacotes é independente do tamanho do pacote, então o número de pacotes recebido por um receptor vezes o tamanho médio da carga útil (ou o correspondente tamanho do pacote) dá a aparente vazão disponível para aquele receptor.

5 B.4 Características dos Relatórios de Qualidade A análise dos relatórios SR e RR provê subsídios para que o emissor pudesse, na indicação de perda de QoS, modificar sua transmissão baseada neste feedback. Os relatórios fazem largo uso de uma contabilidade cumulativa dos parâmetros. Isto é explicado na RFC como sendo uma forma de realizar medidas sobre períodos de tempo curtos ou longos, e para prover resistência contra a perda de relatórios intermediários por possíveis situações de congestionamento da rede. A diferença entre os últimos dois relatórios recebidos pode ser usada para estimar os parâmetros de qualidade de serviço mais recentes. Outra característica importante é a detecção de congestionamentos, podemos usar o campo interarrival jitter como uma medida de curta duração para detectar congestionamento na rede. Por outro lado, a perda de pacotes rastreia congestionamentos persistentes enquanto que a medida de jitter rastreia congestionamentos transientes. Isto acontece porque o jitter aumenta indicando a iminência do congestionamento antes que este gere qualquer perda de pacotes. Como o campo de jitter entre chegadas é somente um retrato do jitter no momento do relatório, é necessário analisar vários relatórios de um receptor ao longo do tempo dentro de uma única rede, para verificar o comportamento dos congestionamentos, e o impacto deles na qualidade da ligação. III METODOLOGIA DE GERAÇÃO E CAPTURA DE TELEFONIA IP Utilizamos uma infra-estrutura baseada no projeto OpenH323 [3], como plataforma operacional de geração e monitoramento de ligações de telefonia IP baseadas em H.323[2]. Esta infra-estrutura é formada por dois programas : openam (ou Open Answer Machine), um tipo de secretária eletrônica de telefonia IP desenvolvida no âmbito do projeto OpenH323, e o programa caller (ou call generator), uma variação do openam desenvolvida inicialmente por [4], e modificada por nós, onde ao invés de receber chamadas, o programa realiza as mesmas enviando um arquivo pré-gravado de áudio na ligação. call generator RTP/RTCP flow RTP/RTCP flow RNP2 openam openam RTP/RTCP flow Fig. 3 Arquitetura de Geração de chamadas e Coleta de Estatísticas openam Na Fig. 3, temos a ilustração da arquitetura desenvolvida. De um lado, a ferramenta de geração de chamadas (NCE/UFRJ) que ativa threads concorrentes e pode realizar até 254 chamadas simultâneas sem precisar ter nenhum recurso de áudio (seja placa de som, ou microfone) envolvido. Do outro lado, espalhado em diversos pontos do backbone da RNP2 por vários estados (AM, DF, CE, MG, PR, SC, RJ), está o programa receptor das chamadas, o openam. Neste pontos remotos, o openam atende as ligações geradas pelo call generator, enviando uma mensagem de áudio e gravando o árquivo de áudio sendo enviado pelo caller. Ambos os programas realizam o armazenamento dos logs das chamadas em arquivos de texto contendo entre outras informações: toda a sinalização H.323 envolvida, todos os pacotes RTCP enviados e recebidos, bem como outras informações sobre o funcionamento interno dos programas, e uma análise final dos parâmetros estatísticos. A.1 Open Answer Machine A Estruturas Internas dos Softwares O openam é uma secretária eletrônica IP desenvolvida usando a biblioteca openh323. Nós utilizamos a versão neste trabalho. Ela trabalha com base em objetos C++ que gerenciam as funções de sinalização H.323 (SETUP, CONNECT,

6 H.245), a pilha de protocolo RTP/RTCP, além dos codificadores de áudio em software como o G.723.1, G.711ulaw, G.711alaw, GSM, MS-GSM, e LPC-10. A figura abaixo (Fig. 4) mostra o diagrama de classes usado pelo openam. Fig. 4 Diagrama de Classes do Openam Toda a execução desta secretária está vinculada ao recebimento de sinalização H.225 (como SETUP para estabelecimento de chamada) por parte de um usuário remoto para que o programa crie os objetos relacionados e responda àquela ligação. Portanto, num primeiro momento o programa fica bloqueado esperando possíveis conexões. Quando outro programa baseado em H.323 se conecta ao openam, ele inicia o objeto #ep, instância de MyH323Endpoint, que por sua vez, acionará a captura do evento MyH.323Endpoint::OnIncomingCall, que criará o objeto MyH323Connection relacionado especificamente aquela ligação. Esta capacidade permite que o programa openam, possa inclusive receber ligações simultâneas, separando-as respectivamente, tendo threads e objetos de cada ligação. E portanto desejável para testes mais críticos de telefonia IP, que envolvam múltiplas conexões VOIP. O objeto #conn, instância de MyH323Connection, cria dois objetos internos importantes, cujas responsabilidades são respectivamente de tocar e gravar mensagens, são eles: o objeto (para tocar) #ogmchannel, instância de PCM ou G7231OGMChannel. Onde OGM indica outgoing message, ou mensagem de boas vindas, que estará associado a um arquivo de áudio pré-gravado e será tocado assim que a ligação for atendida pelo programa. E o objeto (para gravar) #recordfile, instância de PCM ou G7231RecordFile, que criará um novo arquivo (cujo nome será formado pelo horário de sistema do instante de início da gravação) e grava o conteúdo da mensagem sendo enviada nos pacotes RTP pelo emissor. Para entender o procedimento usado por estes importantes objetos, relacionados tanto com o playout da mídia quanto com a gravação, é preciso dizer que existe um mecanismo de gerenciamento de tempo envolvido através do escalonamento dos frames de áudio a serem tocados e gravados. Ambos os objetos precisam de métodos de sincronização de tempo, como o método PCM_OGMChannel::Synchronise, que vai inserindo atrasos caso seja necessário em cada leitura de um frame de áudio, obtido do arquivo pré-gravado e armazenado temporariamente no buffer de playout até o seu encapsulamento. A operação contrária é bastante similar, na escrita do arquivo contendo a gravação, o método PCM_RecordFile::DelayFrame, vai ditando o ritmo de gravação dos frames de áudio que estão armazenados no buffer de recepção. Ou seja, a não ser pela perda de pacotes RTP, não é possível ouvir a degradação obtida pelo atraso de propagação, ao tocar um arquivo de áudio gravado pela secretária posteriormente. Pois esta degradação somente poderia ser percebida em uma conversação interativa, o que não é o caso da secretária.

7 A.2 Modificações para criar o Call Generator e Melhorar a Precisão das Ferramentas Foram realizadas algumas modificações no openam, para que ele pudesse suportar o acionamento automático de uma ligação H.323. Inicialmente, nos baseamos no código-fonte do call generator [4], que usava a versão do openam. As modificações foram as seguintes: Comentar o mecanismo de listernerh323, do openam, que fica bloqueado esperando receber ligações. Trocando este procedimento por uma chamada a um método MakeOutgoingCall. Extender alguns métodos de captura de eventos do H323Endpoint que são específicos para um elemento (endpoint H.323) que realize chamadas ao invés de recebe-las, como OnAlerting, OnConnectionEstablished, OnConnectionCleared, AwaitTermination e o próprio MakeOutgoingCall. No caso do método MakeOutgoingCall, é obtido como parâmetro do vetor de argumentos de entrada do programa, o endereço IP relacionado ao ponto que deve ser chamado, e dentro deste método feita a chamada para este IP. Foi modificado o código do método OnConnectionEstablished do caller e do openam, para fazer acesso a sessão RTP e então pudesse ser ajustada a freqüência de envio de pacotes RTCP para 1 a cada segundo. Anteriormente esta taxa de envio de pacotes RTCP era de a cada 12 segundos (no caso do Netmeeting esta taxa é de 1 pacote RTCP a cada 5 seg.), valor inapropriado para medidas mais precisas dos parâmetros de qualidade. E finalmente no código do caller/openam foi criado mais um parâmetro de entrada (--dejitter), onde pode ser inserido o valor do buffer de compensação de jitter em ms. Tendo como faixa de valores válidos de 20 ms até 10 s. Também foram feitas modificações na biblioteca OpenH323, mais especificamente, nos objetos que controlam o funcionamento do stack RTP/RTCP, onde foi criada uma variável chamada JitterInstant que representa o valor D da fórmula do jitter (seção 2-B1). Complementando, foi modificado o evento de chegada de pacotes RTP para que este pudesse imprimir no log, o valor de D a cada intervalo de dois pacotes consecutivos. Ainda na pilha RTP/RTCP, foi modificado o código para imprimir no log o evento de perda de pacotes, portanto relacionando cada perda com seu respectivo tempo. Todas estas modificações tiveram como objetivo aumentar a capacidade da ferramenta (openam) para realizar medidas mais precisas, no contexto da avaliação de performance do backbone. A.3 Característica das Fases de Play e Record É importante descrever uma característica encontrada no uso desta infra-estrutura de geração e coleta de estatísticas a partir de ligações simuladas. Tanto openam quanto caller, internamente após o estabelecimento da chamada, têm o mesmo comportamento de uma secretária eletrônica, ou seja existem duas fases bem definidas, nesta ordem: a fase de tocar a mensagem OGM, e depois a fase de gravar a mensagem da parte remota. Apesar da comunicação ser, durante toda a ligação, bidirecional (os pacotes RTP são enviados nos dois sentidos enquanto houver arquivos para serem tocados ou gravados) Caso uma das parte cai na fase de gravação, não será mais enviado o arquivo de OGM (Ougoing Message), o programa passa então a transmitir silêncio até que o término da chamada seja acionado por uma das partes. Na fig. 5, temos a ilustração de como isso funciona na prática. De um lado temos o programa caller com um arquivo wav + DTMF 4 como sua mensagem de OGM, enquanto que no lado openam temos somente o arquivo wav. Após ter sido feito o estabelecimento de chamada (fases de Setup/Connect e OpenLogicalChannel no H.245), os programas automaticamente entram no estado de play OGM. Assim nos primeiros segundos o que temos é os dois programas enviando pacotes RTP com o arquivo de áudio, mas nenhum deles gravando. No passo seguinte, na recepção do arquivo de mídia pelo openam, existe um objeto de captura eventos de detecção de DTMF (dígitos) dentro da banda de áudio. Esta funcionalidade faz parte do esforço de flexibilização do openam, pelos programadores do openh323, para que este possa ser estendido para um sistema de Call Center IP no futuro. Pois bem, o

8 DTMF 4, é o que aciona a mudança de estado de play OGM para record file, os outros números (DTMFs) não tem sentido para o programa. Uma vez no estado de record file, o arquivo wav que está sendo tocado remotamente, fica sendo gravado em um arquivo wav local, correspondendo este ao arquivo original mais as degradações sofridas por perda de pacotes nesta comunicação. Quando o arquivo wav que está partindo do caller acaba (outra condição para a mudança de estado), então o caller passa para o estágio de record file, mas já é tarde e o procedimento de término da chamada é ativado no 150 o segundo, no openam. arquivo wav com DTMF 4 Caller Play OGM Fluxos de Mídia na Rede Play OGM Record File Openam arquivo wav sem DTMF Ao receber um DTMF 4 Inband, o estado play muda para record, e para de tocar o arquivo arquivo wav sendo gravado a partir do ponto DTMF 4 término da mensagem OGM do caller, muda o estado de play para record Record File RELEASE Fig. 5 Gravando arquivos degradados no cliente remoto 150 segs. arquivo wav do caller recuperado a partir do DTMF 4 O arquivo wav do caller é chamado de arquivo wav de referência, com ele podemos pesquisar melhor a qualidade perceptual dos usuários frente a rede, comparando subjetivamente este com o arquivo degradado. Para o propósito deste arquivo de referência, construímos um arquivo contendo um locutor contando números pausadamente, isto porque queríamos ter períodos de fala e períodos de silêncio bem definidos. Outra razão para usar a contagem de números é que fica mais fácil buscar no arquivo a posição em segundos de uma degradação. Este arquivo pode ser visualizado com a ferramenta Audacity [5], ferramenta que foi inicialmente concebida para realizar a análise de algoritmos de áudio (Fig.6), e que para nós serve para comparar os arquivos original e degradado. Fig. 6 Visualização do arquivo de referência

9 B Arquivos de Logs Os programas envolvidos nos testes, sejam eles o caller ou openam, geram a cada ligação um extenso arquivo de texto contendo os logs com todas as medidas realizadas (perdas instantâneas, perdas acumuladas, RTT, diferença entre chegadas, jitter suavizado RTCP, entre outras), com cerca de 1 megabyte de tamanho. A este arquivo é dado o nome formado pela par de nomes dos locais onde está sendo realizada aquela ligação, mais um L de local, e dia, hora, minuto e segundo (ex. nceufrj-brasilia-2002-l txt). Esta marcação de tempo é extraída do primeiro pacote contendo o NTP do emissor para o receptor. Desta forma, quando este pacote é recebido no receptor, temos um nome igual apenas diferenciado pela letra R de remoto ao invés do L. Uma preocupação constante nos testes é com relação a sincronização de tempo das medidas, dado que as máquinas podem estar em tempos diferentes, tomamos sempre como base das medidas a máquina emissora, estando esta sendo sincronizada constantemente com os servidores NTP da própria RNP2. Cada arquivo de log tem as seguintes linhas de texto, dos eventos relacionados a recepção de pacotes, importantes para as medidas (Tab.2): 0: RTP Jitter:864de88 RTP Receive statistics: packets=396 octets=95040 lost=0 jitterinstant=0 jitter=10 0: RTP Jitter:864de88 RTP Receive statistics: packets=397 octets=95280 lost=0 jitterinstant=24 jitter=9 0: RTP Jitter:864de88 RTP Receive statistics: packets=398 octets=95520 lost=0 jitterinstant=120 jitter=10 Tab.2 Arquivo de Log com medidas instantâneas No caso, em negrito, temos os tempos de ativação dos eventos relacionado a recepção de pacotes RTP, com as estatísticas instântaneas para cada pacote recebido. No caso, três medidas são particularmente úteis: lost que representará quando um pacote for perdido, jitterinstant ou o valor D da equação do jitter, e o jitter propriamente dito, dada a equação de suavização do RTP, que mostra tendências de congestionamento. Outras linhas de logs importantes são as que demonstram os pacotes RTCP (no caso do caller e openam, eles são pacotes compostos por 1 SR, 1 RR e 1 SDES, verifique no instante de recepção do pacote que é o mesmo para os três relatórios): 0: RTP Jitter:864de88 RTP OnRxSenderReport: ssrc= ntp=2002/10/24-10:12: rtp=95520 psent=398 osent= : RTP Jitter:864de88 RTP OnRxSenderReport RR: ssrc= fraction=0 lost=0 last_seq=0 jitter=39 lsr=0.000 dlsr= : RTPJitter:864de88 OnSourceDescription: ssrc= item[0]: type=cname data="voip@server3.pop-df.rnp.br" item[1]: type=tool data="openam" Tab.3 Arquivo de Log com os pacotes RTCP Nos pacotes RTCP, como mostrado na seção 2, temos os parâmetros envolvidos nos relatórios de emissor (SR) como ssrc (identificação da fonte), ntp (tempo absoluto em formato NTP da máquina emissora), o timestamp RTP daquele pacote SR, entre outras (psent = packet sent). Também no mesmo pacote, podemos verificar um relatório de receptor (RR) da outra fonte (outro fluxo) identifcado por outro número de ssrc, além dos valores da fração de perda (fraction), valor acumulado do número de pacotes perdidos (lost). Um dado importante, é que os valores de LSR (Last Sender Report) e DLSR (Delay Since Last Report) não são preenchidos pelos programas, mas é possível deduzir estes ao comparar os dois logs (local e remoto) e fazer a diferença do tempo de processamento entre pacotes RTCP. Finalmente, o último relatório que compõe este pacote é o SDES, ou relatório de descrição da sessão, que informa a quem pertence determinado fluxo, por ex. o ssrc é da ferramenta (TOOL) openam, localizada em (CNAME) voip@server3.pop-df-rnp.br.

10 C Integração com Outras Medidas Complementares (traceroute e MRTG) Além de realizar uma série de medidas, armazenar um arquivo de áudio alterado e simular perfeitamente uma ligação de telefonia IP baseada em H.323, também foi projetado para este ambiente de coleta, uma forma de integrar informações complementares sobre o estado da rede nos seus nós intermediários para facilitar a exploração da origem de certa falha. Com este propósito, decidimos juntar à ferramenta de geração de chamada, um script desenvolvido em perl, para realizar automaticamente um traceroute do caminho origem da ligação IP até o ponto final. Caso neste caminho, algum roteador do núcleo da rede RNP2 estivesse sendo usado, então o script pode armazenar os valores dos relatórios de estatística MRTG [4] sobre o estado atual daquela interface de rede. Com isso, não somente temos as informações fim a fim, como também temos alguma informação do meio do caminho que pode ser útil. Portanto, um outro arquivo de pouco mais de 500 bytes é gerado a cada ligação tanto na máquina do caller quanto na máquina do openam remoto. Eis um exemplo de um arquivo de traceroute concatenado com as estatisticas de pacotes, vazão em bits e atraso obtidas das páginas web do MRTG dos roteadores do núcleo da RNP2 (como o ) ms ms ms ms (Vazão em bits - Entrada) (Vazão em bits - Saída) (Vazão em pacotes Entrada) (Vazão em Pacotes Saída) (Delay Entrada) (Delay Saída) ms ms Tab. 4 Log do traceroute com integração MRTG RNP2 (RJ-DF) No exemplo, descrito acima (Tab.4), temos uma ligação partindo da máquina (Lab. VOIP NCE/UFRJ) até uma máquina em (Brasília no POP-DF). IV CONSOLIDAÇÃO E VISUALIZAÇÃO DAS ESTATÍSTICAS Como vimos na seção anterior, cada máquina ou espalhada pelos pops RNP ou a máquina interna do lab. VOIP vai gerando 3 arquivos a cada ligação: o arquivo com o áudio degradado com cerca de 2 MB (2 minutos e meio), o arquivo com os logs com cerca de 1.3 MB, e o arquivo contendo o trace daquele instante com cerca de 1 KB. Ou seja, no caso de uma medida sendo realizada a cada hora, temos ao final de 24 horas, cerca de 80 MB em arquivos na máquina remota. Portanto, faz-se necessário um mecanismo de limpeza dos arquivos e de consolidação dos logs em base de dados centralizada. Assim sendo, foi desenvolvido um script perl que é acionado todo dia em horários de pouca utilização da internet, como de madrugada, para fazer este serviço. Nestes horários quando o script entra em ação ele abre uma conexão TCP com uma máquina com alta capacidade do lab. VOIP, e envia todos os arquivos. Uma vez nesta máquina centralizadora dos logs, entra em ação um script de pós-processamento dos dados cujo objetivo é extrair medidas estatísticas (como média, desvio padrão, valor máximo e valor mínimo) que possam resumir todo o log de uma ligação. Isso é importante para termos um panorama mais amplo sobre as ligações ao longo do dia. Embora as medidas mais precisas não sejam perdidas, pois elas permanecem armazenadas neste servidor para caso, seja necessário visualizá-las. O diagrama abaixo (Fig.7) ilustra o sistema de consolidação de arquivos dos logs estatísticos:

11 Caller Data RNP Openam... Data Data Servidor Web GTVOIP Fig.7 Consolidando os arquivos logados Openam Dentro deste servidor de consolidação, além da funcionalidade de pós-processamento e armazenamento dos logs, também foram desenvolvidos interfaces Web para visualização gráfica dos dados. Estas interfaces estão divididas em dois níveis: Visualização Condensada de Informações Visualização das Estatísticas de 1 Ligação em Particular A Visualização Condensada de Informações Esta interface Web tem como objetivo condensar a informação de um período (em dias) de testes de VOIP em um grupo de gráficos (RTT, perda e jitter) resumido. Tendo como entrada principal, quais dois pontos de ligação serão escolhidos, o sentido da ligação (de emissor para receptor ou vice-versa), qual a data de início e a data de término desta condensação. A página web (Fig.8) a seguir ilustra esta interface: Fig. 8 Página Web de Condensação de Logs Estatísticos

12 Uma vez escolhido o período, é gerado automaticamente através de bibliotecas perl (como GDGraph.pm, DateRange.pm, Date.pm [6]) uma página web dinâmica contendo um conjunto de 3 gráficos: gráfico do RTT, perda e jitter. Fig. 9 Exemplo de Resumo RTT (Round Trip Time) ao longo do dia 12/09/2002 das 14:15 às 23:15. Cada ponto do eixo X deste gráfico de RTT (Fig.9) representa uma ligação que foi feita contendo o dia e hora da mesma. Sendo que as linhas coloridas, respectivamente descritas na legenda, informam quais os pontos máximos, mínimos, médios e o desvio deste período de ligações. Ao final desta página de visualização condensada é possível escolher uma destas ligações para explorar mais detalhadamente os parâmetros desta ligação. Fig. 10 Detalhe da página Wb, onde é feita a escolha de uma ligação a ser detalhada quanto aos seus parâmetros ao longo dos 3 minutos B Visualização das Estatísticas de 1 Ligação em Particular Depois de escolher uma ligação, e clicar em Submit, uma nova página web é dinâmicamente gerada, contendo os detalhes daquela ligação. Estes detalhes são: o round-trip time, calculado pela integração dos valores dos relatórios RTCP

13 SR/RR de dois pacotes consecutivos nos dois logs (ou seja, cerca de 150 RTCP SR/RR). A perda instantânea e o jitter suavizado e parâmetro D do jitter instantâneo). A figura abaixo (Fig. 11) ilusta um gráfico RTT detalhado: Fig. 11 Detalhamento de uma ligação, valores de RTT ao longo de 150 segundos de ligação Estas informações detalhadas são todas aquelas armazenadas nos arquivos de logs gerados ao longo da ligação, portanto, é possível usar estes dados para gerara automaticamente estes gráficos. Com a sobreposição dos gráficos destes principais parâmetros de qualidade de serviço é possível verificar como os problemas de RTT, perda e jitter se inter-relacionam naquela ligação com uma maior facilidade. Pretende-se em breve, integrar neste gráfico detalhado, também a informação do caminho (traceroute) utilizado, bem como as estatísticas obtidas no MRTG naquele instante de ligação. IV CONCLUSÕES E TRABALHOS FUTUROS Neste trabalho, apresentamos um conjunto de ferramentas de geração, monitoramento e coleta de estatísticas a serem utilizados para verificar o nível de qualidade que ligações VOIP sofrem ao serem feitas através da RNP2. Entre as contribuições alcançadas temos, um estudo dos parâmetros de feedback de qualidade de serviço utilizado pelo protocolo RTP/RTCP. A modificação do programa de secretária eletrônica (openam) do projeto OpenH323 aumentando a precisão das medidas, bem como viabilizando uma flexibilização da geração de relatórios RTCP em um intervalo pequeno, e modificando o buffer de compensação de jitter. Também foi estudado, um método de gravação de arquivo de áudio, que capture as características de degradação por perda obtidas na transmissão de multimídia na RNP2. E criado um arquivo de referência para posterior avaliação subjetiva por parte de usuários. O sistema de geração de ligações de telefonia IP simuladas e coleta de estatísticas é pequeno (com cerca de 10 MB entre os scripts e programa executável), leve (não demanda muitos recursos computacionais e 80MB no máximo em disco por dia) e portado para vários ambientes como Linux e FreeBSD, podendo também ser portado para Windows facilmente. Alguns parâmetros usados nos testes preliminares foram obtidos da literatura, como o tamanho considerado bom para o buffer de compensação de jitter para a Internet pública, com cerca de 150 ms [7], e o tamanho da ligação fixada em cerca de

14 2 minutos e meio, valor este que representa a grande maioria de ligações VOIP na rede MCI segundo estudo feito em [8]. Está previsto ainda uma fase de validação destes dados baseando-se na ferramenta Rude/Crude [9]. Além disso, foi desenvolvido todo um sistema de recolhimento dos logs e arquivos wav dos pontos remotos e a centralização dos mesmos em uma máquina com excelente poder de processamento e armazenamento, para consolidar estes logs, e propiciar uma visualização online dos resultados. Entre os passos futuros, queremos associar as medidas detalhadas aos seus respectivos arquivos wav, para que a pessoa que estiver analisando uma ligação possa verificar subjetivamente como está a qualidade do áudio (tocando este), verificando como uma perda em rajada ou uma perda constante no tempo pode atrapalhar uma conversa ao comparar com o arquivo de referência. Outra proposta é inserir as informações de rota e estado dos links intermediários no detalhamento de uma ligação. Para tentar verificar os possíveis motivos de uma falha de qualidade, e então sugerir alguma atualização ou correção. Também vislumbramos o aprofundamento nas questões da avaliação automática da qualidade perceptual da mídia através de algum algoritmo padronizado, como o e-model da ITU-T [10], inclusive já foram desenvolvidas algumas experiências neste sentido no âmbito do projeto TIPHON, inclusive testando ligações de VOIP [11]. Essa será a continuação natural deste trabalho. Finalmente, pretendemos desenvolver um novo nível de páginas de resumo, que possa extrair todas as informações sobre ligações entre dois pontos não só pelo período, mas também durante toda a experiência. Também queremos diponibilizar um buscador web, para localizar as ligações considerada piores. V BIBLIOGRAFIA [1] IETF RFC 1889 RTP: A Transport Protocol for Real-Time Applications. [2] ITU-T Recommendation H.323, Packet-Based Multimedia Communications Systems, Setembro [3] [4] Milen Stoychev. (page visited 05/2002) [5] [6] [7] Athina P. Markopoulou, Fouad A. Tobagi, Mansour J. Karam. Assessment of VoIP Quality over Internet Backbones. IEEE Infocom [8] Caceres et al., 2000] J. van der Merwe, R. Cceres, Y-H. Chu, C. Sreenan. Mmdump - A Tool for Monitoring Internet Multimedia Traffic. ACM Computer Communication Review, 30(4), October [9] - Sven Ubik and Vladimir Smotlacha. Low-Cost Precise QoS Measurement Tool. CESNET Technical Report, [10] ITU-T Recommendation G.107, The Emodel, a computational model for use in transmission planning, December [11] ETSI TS Quality of Service (QoS) measurement methodologies. TIPHON.