Resumo

  • A RFC 3095 exigiu que o ROHC começasse em modo unidirecional, usando atualizações periódicas onde não havia canal de retorno.
  • O descompressor podia pedir modos bidirecionais otimista ou confiável; o feedback confirmava o contexto de compressão, não a entrega fim a fim.

O primeiro pacote não podia presumir resposta

Em um enlace de rádio, cabeçalhos IP, UDP e RTP podiam superar uma pequena carga de voz. Omitir campos constantes ou previsíveis economizava capacidade, mas obrigava o receptor a reconstruí-los a partir de estado compartilhado. Uma atualização perdida podia inutilizar pacotes posteriores que o enlace entregara corretamente.

A RFC 3095 separou estado de modo. Estados IR, FO e SO descreviam a maturidade do modelo do compressor; ausência de contexto, contexto estático e contexto completo descreviam o que o descompressor podia reconstruir. O modo respondia a outra pergunta: que autoridade real existia no caminho de volta?

A regra inicial era conservadora: a compressão tinha de começar em U-mode. Sem retorno, o compressor avançava pela abordagem otimista quando julgava ter repetido informação suficiente. Temporizadores, atualizações periódicas e mudanças irregulares o faziam voltar a formatos mais ricos. Confiança razoável limitava o preço do silêncio; não o transformava em prova de recebimento.

O descompressor abria os modos bidirecionais

O compressor não podia declarar um canal inverso por conta própria. Depois de receber um pacote, o descompressor podia enviar feedback com o modo desejado e iniciar a passagem para O-mode ou R-mode.

O sentido da decisão importava. O compressor via o que enviara; o descompressor via se a reconstrução funcionava. Quem observava a falha imediata pedia outra disciplina a quem escolheria o próximo formato.

A RFC 4815 esclareceu depois que a transição usava uma negociação em três etapas para mover ambos de forma coerente. Pacotes em torno da confirmação precisavam usar a regra antiga ou nova no ponto exato. O nome “confiável” não substituía o procedimento.

O modo otimista economizava feedback

O-mode usava o retorno para pedidos de recuperação e, opcionalmente, confirmações de atualizações significativas. Atualizações puras de número de sequência não recebiam o mesmo tratamento, e não havia atualizações periódicas. O objetivo era eficiência com uso esparso do canal inverso.

O risco mudava de lugar. O modo reagia a dano detectado, mas rajadas longas de perdas ou erros podiam invalidar o contexto mais vezes do que em R-mode. Um NACK descrevia a reconstrução local; não provava áudio inteligível, consumo pela aplicação ou resultado para o usuário.

O modo confiável protegia referências

R-mode usava o retorno com mais intensidade. Confirmava todas as atualizações de contexto, inclusive do número de sequência, embora nem todo pacote alterasse o contexto. Pelo princípio de referência segura, apenas pacotes com CRC de sete ou oito bits podiam atualizar o contexto e servir de referência futura.

Era uma confiabilidade específica: reduzir propagação de perda e dano quando cabeçalhos ou feedback fossem corrompidos. Erros residuais continuavam possíveis. R-mode não certificava a carga, a aplicação nem o caminho inteiro.

O caminho de volta entrava na conta

A RFC 3096 definiu o cenário: enlaces com erros e longos tempos de ida e volta, incluindo WCDMA, EDGE e CDMA-2000. Exigiu cabeçalho reconstruído semanticamente idêntico ao original, ou descarte do pacote, e procurou reduzir a propagação de erros.

O cálculo de sobrecarga tinha de incluir canais de controle e feedback. Um cabeçalho mínimo na ida não representava o custo total se dependia de confirmações e recuperação na volta. A RFC 3409 tornou a dependência explícita: U-mode não precisava de retorno; O-mode e R-mode precisavam que a camada inferior transportasse mensagens inversas prontamente.

Evolução de texto não era prova de implantação

A RFC 4815 reuniu correções. A RFC 4995 separou a estrutura dos perfis e registrou que implementadores haviam considerado partes da RFC 3095 complexas ou obscuras, mantendo a compatibilidade. A RFC 5225 definiu perfis ROHCv2 simplificados para perdas e reordenação. A RFC 3241 padronizou a negociação sobre PPP.

Esses documentos provam especificação contínua, não uso por operadora identificada, economia medida de espectro, handover bem-sucedido ou interoperabilidade entre produtos específicos.

A fronteira histórica é mais útil: a RFC 3095 tratou o retorno como capacidade direcional, custosa e observada por quem reconstruía. Separou previsão do compressor, confirmação local do descompressor e resultado fim a fim que exigia outra evidência.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3095.html
  2. https://www.rfc-editor.org/info/rfc3095
  3. https://datatracker.ietf.org/doc/rfc3095/
  4. https://www.rfc-editor.org/rfc/rfc3096.html
  5. https://www.rfc-editor.org/info/rfc3096
  6. https://datatracker.ietf.org/doc/rfc3096/
  7. https://www.rfc-editor.org/rfc/rfc1144.html
  8. https://www.rfc-editor.org/rfc/rfc2508.html
  9. https://www.rfc-editor.org/rfc/rfc3241.html
  10. https://www.rfc-editor.org/rfc/rfc3409.html
  11. https://www.rfc-editor.org/rfc/rfc4815.html
  12. https://www.rfc-editor.org/info/rfc4815
  13. https://www.rfc-editor.org/rfc/rfc4995.html
  14. https://www.rfc-editor.org/rfc/rfc5225.html