As características do discurso humano necessitam de um fluxo de áudio contínuo. Para tal, é necessário recorrer ao uso de protocolos em tempo-real que visam minimizar os efeitos da rede. Estes protocolos, para além de ordenarem as mensagens recebidas conforme a ordem temporal pela qual foram geradas, também oferecem meios para controlar a qualidade de serviço da transmissão. Nesta secção serão abordadas várias características dos dois principais protocolos em tempo-real.
2.3.1
Real-time protocol / Real-time Control Protocol
O RTP é um protocolo que tem como função auxiliar o transporte do fluxo de áudio em tempo-real. As amostras de áudio codificado são encapsuladas em pacotes RTP que é transportado através do UDP [Tanenbaum, 2002]. Assim sendo, o áudio vai sendo transportado via RTP/UDP/IP que no final terá um cabeçalho de 40 bytes em que 12 são do RTP, 8 do UPD e 20 do IP. Os parâmetros mais importantes do cabeçalho do RTP são [Schulzrinne, 2003]: (i)
sequence number, que tem como objectivo numerar os pacotes para quando estes ao chegar ao
seu destino sejam detectados os pacotes perdidos, ou que se encontrem fora de ordem; (ii) após ser feita a amostragem do primeiro byte de áudio a ser incluído no pacote RTP, é criado o
timestamp, que reflecte o relógio na altura a que foi feita a amostragem. Este é o parâmetro que
permite que as amostras de áudio sejam exibidas no seu destino, na ordem temporal correcta e à mesma taxa em que os pacotes foram gerados.
O RTCP é o protocolo que, associado ao RTP é capaz de monitorizar a entrega e a QoS de um fluxo de áudio do VoIP. Porém, não faz parte das suas funções garantir a sua QoS [Tanenbaum, 2002]. O seu funcionamento é baseado na transmissão periódica de pacotes de controlo para todos intervenientes na sessão RTP. O RTCP tem como funções principais [Schulzrinne, 2003]: (i) fornecer informação sobre a qualidade da transmissão do fluxo de áudio, isto é, realiza o controlo de fluxo e congestionamento; e (ii) transportar informações de controlo da sessão, como o caso da identificação dos participantes que é utilizado para a apresentação no interface do utilizador. O RTCP utiliza os seguintes parâmetros para monitorizar a QoS: (i) o
faction lost, que representa o número de pacotes RTP perdidos desde do envio da última
12
de chegada entre os pacotes RTP; e (iii) o Delay Since Last SR, sendo este o valor que representa o atraso entre recepção da última mensagem e o envio desta.
2.3.2
Inter-Asterisk eXchange
O Inter-Asterisk Exchange (IAX2) é um protocolo desenhado para optimizar o transporte de fluxo de voz em tempo-real, conjugando a sinalização e a transmissão de média de uma chamada num só protocolo. Por esta razão, o IAX2 tem dois tipos de mensagens com diferentes características de transporte. As mini frames são as mensagens utilizadas pelo IAX2 para o transporte do fluxo de média, estas têm 4 bytes de cabeçalho, ao contrário do RTP que utiliza 12
bytes de cabeçalho. Outra diferença entre o RTP e o IAX2 é que o IAX2, para o transporte de
mensagens de monitorização da QoS do fluxo de áudio, utiliza as mensagens destacadas para a sinalização, ao contrário do RTP que usa o RTCP para esse efeito. Isto faz com que comparando o IAX2 e o RTP, usando um codec de 8 kbps e com agregação em pacotes de 20 byte em 20 ms, o IAX2 sobrecarrega 20% e o RTP 60% da largura de banda com cabeçalhos segundo os estudos feitos por Spencer [Spencer, 2010].
O IAX2 utiliza as mensagens mini frame para o transporte de média sobre UDP. O transporte destas mensagens é não fiável, contudo, o receptor é capaz de controlar o QoS através das mensagens full frame, que contêm elementos de informação definidos pelo próprio protocolo. A Tabela 2 indica os vários elementos utilizados neste controlo.
13
Tabela 2- Descrição dos elementos do IAX24
Nome Information Element Descrição
RR JITTER Indica o valor do jitter recebido.
RR LOSS Guarda informação sobre a perda de informação para uma sessão,
incluindo a percentagem da perda e o número de frames perdidas.
RR PKTS Indica o número total de frames recebidas no contexto de uma sessão
RR DELAY
Indica o valor esperado do atraso da frame em milissegundos, também conhecido por timeout delay. Caso a frame ultrapasse este tempo é descartada.
RR DROPPED Indica o número de frames que foram descartadas no contexto da
sessão
RR OOO Indica o número de frames recebidas fora de ordem no contexto da
sessão.
As seguintes mensagens (Tabela 3) full frame têm como função monitorizar a rede. São obrigatórias em todas as sessões e têm como objectivo fornecer informação do estado da sessão e dos seus intervenientes, sendo que esta particularidade é uma das características que tornam este protocolo único, pois é capaz, entre outras coisas, de verificar se os intervenientes se encontram
online.
4
14
Tabela 3 - Descrição das Mensagens IAX25
IAX2 Message Name Pedido/Resposta Information Elements incluído Descrição
POKE Pedido Não
Mensagem com um propósito muito similar ao PING, contudo, só é enviada para um peer quando não existe uma sessão estabelecida.
PING Pedido Não
Esta mensagem é utilizada para testar a ligação entre os dois peers. Por defeito é enviada a cada 20 s e aguarda por uma resposta PONG.
PONG Resposta RRJITTER, RRPKTS, RRDELAY e/
ou RRDROPPED
Resposta à mensagem PING onde envia informações sobre o estado da rede.
LAGRQ Pedido Não
Para avaliar o lag entre os dois peers é enviada esta mensagem para comparação com o timestamp da resposta.
LAGRP Resposta Não
Depois desta mensagem pelo
jitter buffer, o peer remoto
deve responder ao pedido LAGRQ para se calcular o
lag entre os dois peers.