• 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. Complementando, esta mudança, foi alterado o evento de chegada de pacotes RTP para poder imprimir no log, o valor de D a cada intervalo de dois pacotes consecutivos (ver seção 2.2). • Outra mudança na pilha RTP/RTCP foi à alteração do código para imprimir no log o evento de perda de pacotes, portanto relacionando cada perda com seu respectivo tempo mais próximo. Todas estas modificações tiveram como objetivo aumentar a capacidade da ferramenta (openam) em realizar medidas mais precisas, no contexto da avaliação de performance do backbone. 3.3 - Característica das Fases de Play e Record É importante descrever uma característica não modificada nos programas que formam a infra-estrutura de coleta devido a sua complexidade. Tanto openam quanto caller, internamente, após o estabelecimento da chamada, têm o mesmo comportamento em suas máquinas de estado, tendo duas fases bem definidas, nesta ordem: a fase de tocar a mensagem OGM, e depois a fase de gravar a mensagem vinda da parte remota. Não se podem realizar as duas ao mesmo tempo. 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 partes caia na fase de gravação, não será mais enviado o arquivo de OGM (Ougoing Message), e o programa passará então a transmitir silêncio, até que o término da chamada seja acionado por uma das partes. Na Fig. 3, temos a ilustração de como isso funciona. 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 no H.225 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 que captura eventos relacionados à detecção de DTMF (dual-tone multi-frequency), os dígitos discados dentro do próprio fluxo de áudio. Esta funcionalidade de detecção de DTMF faz parte do esforço de flexibilização do openam pelos programadores do openh323, para que este possa ser estendido futuramente para um sistema de Call Center IP. No caso, somente o DTMF 4, é o que aciona a mudança de estado de “play OGM” para “record file”, os outros dígitos (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 ao arquivo original mais as degradações sofridas por perda de pacotes nesta comunicação. Outra condição para a mudança de estado acontece, quando o arquivo wav que está partindo do caller acaba (Fig.3). Então o caller passa para o estágio de “record file”,

Inicio Próximo