Resumo
- A RFC 3545 repetia valores de contexto alterados em N+1 pacotes para dar ao descompressor uma chance de ressincronizar, desde que a sequência de perdas ficasse dentro do limite assumido para o enlace.
- O HDRCKSUM opcional ajudava a conferir cabeçalhos reconstruídos quando o checksum UDP do IPv4 era zero, mas não cobria o Identification do IPv4; acima de N perdas consecutivas, era mais seguro invalidar o contexto e pedir seu estado.
A verificação tinha um ponto cego. A RFC 3545 permitiu que o compressor substituísse um checksum UDP IPv4 nulo por um checksum de cabeçalho de 16 bits. Assim, o descompressor podia conferir a reconstrução. Mas o Identification do IPv4 não estava entre os campos verificados. Em um enlace com poucas perdas, essa omissão podia ficar escondida em um mecanismo de recuperação mais amplo. Depois de perdas consecutivas demais, ela mudava o que “recuperado” realmente podia significar.
O CRTP, definido na RFC 2508, comprime cabeçalhos IP, UDP e RTP mantendo contexto compartilhado nas duas pontas. Um cabeçalho completo estabelece esse estado; os pacotes seguintes podem transportar alterações ou diferenças. Se um pacote que carrega uma atualização se perde, o compressor avança e o descompressor fica para trás. A divergência talvez só apareça quando chega outro pacote comprimido. Em um enlace com muito atraso, pedir reparo do contexto custa pelo menos uma viagem de ida e volta, e mais pacotes podem ser descartados nesse intervalo.
A RFC 3545 responde com repetição e um limite explícito. Ela define N com base no comportamento de perdas do enlace: a probabilidade de perder mais de N pacotes adjacentes deve ser pequena. Quando a atualização aparece em N+1 pacotes consecutivos, ao menos uma cópia deve chegar se a rajada não passar de N. O descompressor pode aplicar o algoritmo “twice” para reconstruir um intervalo limitado e conferir o resultado com o checksum UDP ou, quando aplicável, com o HDRCKSUM. O protocolo aumenta a tolerância; não garante que toda rajada siga o modelo.
O número de sequência do enlace tem apenas quatro bits e reinicia a contagem a cada 16 pacotes. Por isso, uma diferença observada nem sempre separa muitas perdas de um reordenamento em que o pacote mais novo chegou antes. Se houver uma interpretação plausível com menos de N+1 perdas, o descompressor pode tentar a reconstrução correspondente e validá-la. Quando a interpretação razoável passa de N, a regra para IPv4 é mais clara: não continuar adivinhando com “twice”; invalidar o contexto e enviar CONTEXT_STATE para que o compressor restaure o estado compartilhado.
É aí que a cobertura do checksum importa. O HDRCKSUM pode ser usado quando o checksum UDP IPv4 original vale zero; ele é incluído para a conferência e removido pelo descompressor. Não se aplica ao IPv6, que não permite checksum UDP nulo. Ainda assim, o checksum de cabeçalho não verifica o Identification do IPv4. Depois de mais de N perdas, um checksum válido não preenche esse campo ausente: a RFC 3545 orienta invalidar o contexto incerto. Como o IPv6 não tem o campo de identificação IPv4, sua regra de recuperação pode ser diferente.
A rajada de atualização tem também uma proteção de identidade própria. Se um campo constante do contexto mudar enquanto N+1 pacotes FULL_HEADER estão sendo enviados, o compressor precisa iniciar outra rajada e mudar o número de geração. Sem isso, o descompressor poderia confundir duas rajadas sobrepostas com uma tolerância maior e não perceber a dessincronização. As mensagens CONTEXT_STATE também devem ser repetidas. Esses mecanismos não provam que um dispositivo específico habilitou a extensão nem que um aplicativo RTP reproduziu a carga útil.
A lição histórica é pequena, mas relevante para a operação: um checksum só prova os campos que cobre, uma reconstrução limitada não é entrega, e reparar contexto não confirma o recebimento da mídia. Uma verificação local válida pode coexistir com um Identification IPv4 não verificado. Quando as perdas passam do limite assumido, invalidar não é desistir da recuperação; é recusar transformar uma sequência ambígua em certeza falsa.
Fontes
- RFC 3545 — Enhanced Compressed RTP
- RFC 3545 — registro do RFC Editor e acesso a erratas
- RFC 3545 — histórico do Datatracker
- RFC 2508 — compressão de cabeçalhos IP/UDP/RTP
- RFC 3544 — compressão de cabeçalho IP sobre PPP
- RFC 3095 — Robust Header Compression
- RFC 3550 — RTP: protocolo de transporte para aplicações em tempo real
- RFC 3711 — Secure Real-time Transport Protocol
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
