O tamanho do cabeçalho RTP é de 12 bytes, o do UDP de 8 bytes e do IP de 20 bytes, totalizando 40 bytes. Considerando o payload IP de 20 bytes, só de cabeçalho teríamos 66,66% da banda da conexão.
Aí é que entra o protocolo CRTP, que, na maior parte do tempo, consegue uma compressão de cabeçalho de 40 para 2 bytes, ou para 4 se considerarmos o checksum UDP. Essa compressão corresponde a uma redução de até 95% na sobrecarga (overhead) referente aos cabeçalhos.
A operação CRTP é simples, como apresenta a Figura 3. O tráfego total destinado a uma determinada interface é classificado, e o que for RTP é separado para compressão. O tráfego RTP é, então, processado num compressor e colocado novamente na fila para ser trasmitido.
Figura 3 - Compressão de cabeçalho RTP
Nos gateways VoIP Cisco, essa compressão é habilitada na interface serial, como mostrado no exemplo abaixo:
interface serial2/1
ip rtp header-compression
encapsulation ppp
ip rtp compression-connections 25
A compressão CRTP é bastante útil em conexões de baixa velocidade (64 Kbps, p. ex.), mas também possui desvantagens. Se for habilitada compressão RTP, o roteador só funcionará em process switch em vez de fast switch, o que, combinado com a sobrecarga da execução CRTP, pode causar queda de desempenho do mesmo. Portanto, o uso do CRTP não é sugerido em enlaces de alta velocidade, uma vez que a relação custo versus benefício pode não compensar.
1 - O protocolo RTP (Real-time Transport Protocol) será apresentado no próximo artigo sobre Telefonia IP.
3.2 Fragmentação e interleaving
No modelo apresentado na Figura 1, considere a existência de uma sessão FTP entre os dois pontos. Se, no momento da chegada de um pacote de voz, o roteador estiver processando um grande pacote FTP, o sinal de voz para o receptor chegará com pausas e, subjetivamente, soará como soluços. Se as pausas forem demoradas, o sinal pode até perder a inteligibilidade. Isso acontece, principalmente, em conexões com grande MTU (Maximum Transmission Unit). Essa situação é bastante inadequada para tráfego sensível a retardo.
Figura 4 - Fragmentação e interleaving
As técnicas de fragmentação e interleaving, ou LFI (Link Fragmentation and Interleaving), amenizam esse problema (ver Figura 4). A fragmentação consiste em quebrar, ou fragmentar, grandes datagramas ("jumbogramas") em partes menores. Já as técnicas de interleaving intercalam os pacotes menores, incluindos os de voz, entre os "pedaços" do "jumbograma" para posterior transmissão. Essas técnicas são bastantes úteis em enlaces de baixa velocidade, reduzindo o atraso e a variação deste, o chamdo jitter. Há duas implementações que são apresentadas a seguir: MPPP (Multilink PPP) e FRF.12 (Frame Relay Fragmentation 12) do Frame Relay Forum.
Multilink PPP
A ativação LFI requer a configuração do MPPP com interleaving e encapsulamento PPP, permitindo que grandes pacotes sejam fragmentados para satisfazer os requisitos de retardo do tráfego de voz. Os pacotes menores, que não são encapsulados no multilink, são transmitidos entre os fragmentos dos pacotes maiores. Ao se ativar a funcionalidade para interleaving, uma fila especial é alocada para o tráfego sensível a retardo, provendo uma certa priorização.
A IETF publicou a Internet draft MCML (Multiclass Extensions to Multilink PPP), que provê quase todas as funcionalidades LFI. Nos roteadores Cisco, o MPPP é ativado através de um template de interface virtual. Assim, um exemplo de configuração seria:
interface virtual-template 1
ppp multilink
encapsulated ppp
ppp multlink interleave
ppp multilink fragment-delay 20
ip rtp reserve 16384 100
A configuração acima ativa o multilink com atraso máximo de 20 ms entre os fragmentos e reserva uma fila especial para priorização de tráfego, através do comando ip rtp reserve 16384 100, onde "16384" é o número da porta e "100" indica a faixa de portas (até 16484) para os quadros UDP a serem priorizados.
Em geral, o MPPP é utilizado em conjunto com WFQ e precedência IP ou RSVP, para assegurar qualidade de serviço na transmissão do pacote. Entretanto, o seu uso não é recomendado em conexões maiores que 2 Mbps.
Especificação FRF.12
O padrão FRF.12, também conhecido como FRF.11 Annex C, provê funcinalidades para fragmentação fim-a-fim e interleaving de frames num mesmo PVC (Permanent Virtual Circuit). Sua utilização é recomendada, não nos PVCs que trafegam voz, e sim nos PVCs de dados que compartilham a mesma conexão física dos de voz.
Em voz sobre IP, os pacotes não devem ser fragmentados, mas podem ser intercalados entre os fragmentos. É importante também que o tráfego de voz sobre IP não exceda a CIR (Committed Information Rate) do PVC Frame Relay, o que pode degradar a qualidade do sinal. Para isso, pode-se utilizar o FRTS (Frame Relay Traffic Shaping). O trecho a seguir apresenta a configuração de uma interface com as condições citadas.
!
interface Serial2/0.1 point-to-point
ip unnumbered Ethernet0/0
no ip directed-broadcast
frame-relay ip rtp header-compression
frame-relay interface-dlci 100 class fr-class-voip
! [...]
map-class frame-relay fr-class-voip
frame-relay cir 64000
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 64000
no frame-relay adaptive-shaping
frame-relay fair-queue
frame-relay fragment 160
frame-relay ip rtp priority 16384 16383 48
!
Quando a fragmentação é utilizada com tráfego FRF.11, que é a implementação do Frame Relay Forum para VoFR - Voz sobre Frame Relay, os dados são transmitidos no formato FRF.11 Annex C. Nesse caso, independente do tamanho, todos os pacotes de dados irão conter cabeçalho de fragmentação. Esse tipo de fragmentação não é recomendada para uso com voz sobre IP.
