�� RTP timestamp (32 bits) – corresponde ao instante de tempo (normalmente múltiplo da unidade de amostragem de áudio) em que o áudio, pertencente ao último pacote RTP, foi enviado por determinada 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 um pacote SR foi gerado. �� Fraction lost (8 bits) – Esta fração é definida pelo número de pacotes perdidos dividido pelo número de pacotes esperado. Tratando-se de informação do RR. �� Cumulative number of packets lost (24 bits) – O número total de pacotes de dados RTP 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 campo do RR chamado “extended highest sequence number received”. �� 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 expresso sempre como um inteiro positivo, ou seja, se o jitter for negativo, ele é apresentado com o sinal invertido. 2.1. Características dos Relatórios de Qualidade Os relatórios SR e RR provêem subsídios para que o emissor possa, na indicação de perda de QoS, modificar seus buffers na recepção e transmissão, ou trocar o codificador, baseando-se neste feedback. Os relatórios fazem largo uso de uma contabilidade cumulativa dos parâmetros. Isto é explicado na RFC do RTP[1], como sendo uma forma de realizar medidas sobre período de tempo, curtos onde 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, e longos, para prover confiabilidade frente a perda de relatórios intermediários em possíveis situações de congestionamento da rede. Outra característica importante é a detecção de congestionamentos, onde podemos usar o campo interarrival jitter como um indicativo. Assim, enquanto a perda de pacotes rastreia congestionamentos persistentes, a medida de jitter vai rastrear 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. Recentemente, novos relatórios RTCP têm sido propostos para melhor representar os parâmetros de qualidade de serviço para voz sobre IP [5], mas veremos que nosso ambiente permite capturar todos os pacotes necessários para também obter estas novas estimativas sugeridas devido à característica de granularidade.

Inicio Próximo