Resumo

  • O formato Interleaved/Bundled de RFC 3558 distribui quadros EVRC ou SMV de 20 milissegundos por vários pacotes RTP, transformando uma perda em apagamentos separados em vez de uma lacuna contínua.
  • maxptime e maxinterleave são limites declarados sobre dimensões diferentes. Eles não demonstram alocação de memória, reconstrução dentro do prazo, ingestão do decodificador ou qualidade percebida.

É fácil colocar parâmetros de sessão numa única coluna chamada “latência”. Esse atalho destrói a arquitetura que os parâmetros deveriam tornar auditável.

RFC 3558, publicado em julho de 2003 como Proposed Standard, define cargas RTP para os vocoders EVRC e SMV. Ambos produzem um quadro a cada 20 milissegundos. O emissor pode agrupar quadros consecutivos ou entrelaçá-los por uma sequência de pacotes. Cada escolha consome recursos distintos.

O pacote é a unidade que a rede perde. O quadro é a unidade temporal que o decodificador espera. O grupo de interleaving é o estado que liga as duas.

B e L não são a mesma alavanca

O primeiro octeto do formato carrega LLL, comprimento de interleaving, e NNN, índice no grupo, cada um com três bits. O segundo contém Mode Request e um contador de cinco bits. Como o contador registra um a menos, ele representa de um a 32 quadros no pacote.

Quando LLL vale zero, há bundling sem interleaving. Quando é positivo, NNN não pode ser maior que LLL. Com B quadros em cada pacote e comprimento L, o grupo cobre B×(L+1) quadros em L+1 pacotes RTP. O pacote N leva posições N, N+(L+1) e as seguintes no mesmo passo.

Aumentar B coloca mais duração em cada datagrama. Aumentar L espalha posições adjacentes por mais datagramas. Ambos podem ampliar o estado do receptor, mas alteram o padrão de falha de modos diferentes. Tratar B e L como uma única “configuração de voz” impede atribuir o efeito observado ao controle correto.

Os pacotes seguem NNN crescente para reduzir espera. Ainda assim, o receptor precisa converter a ordem de chegada na ordem temporal dos quadros. “Reduzir” não significa eliminar atraso nem garantir que o último membro chegue antes do playout.

maxptime responde quanto cabe em um pacote

maxptime declara a maior duração de mídia permitida num pacote. Para esse registro, o padrão é 200 milissegundos. Ele limita o bundling e, portanto, a quantidade de fala concentrada num único evento de perda.

Esse parâmetro não informa quantos pacotes compõem o grupo, quanto tempo o receptor espera por reordenação ou quantas posições futuras já estão guardadas. Também não prova que o emissor respeitou o valor. É preciso observar a carga real e calcular os milissegundos representados.

Uma violação de maxptime deve registrar o valor negociado, a duração observada, o pacote e a versão do empacotador. Uma conformidade aparente deve continuar distinta de qualidade: um pacote dentro do limite ainda pode chegar tarde ou ser inválido.

maxinterleave responde até onde os quadros se espalham

O receptor anuncia com maxinterleave o maior L que aceita; se ausente, o padrão é cinco. Em sessão um a um, o emissor não deve superar a declaração. O receptor pode reduzir o teto durante a sessão.

O teto permite dimensionar o máximo de estado esperado. Não reserva bytes, não fixa prioridade de processo, não sincroniza sozinho a mudança e não garante que a fila permaneça abaixo do limite. Um valor aceito na oferta é capacidade declarada, não recibo de recurso.

Para provar execução, preservar oferta, resposta, instante efetivo, primeiro grupo conforme, bytes alocados, ocupação máxima, número de grupos incompletos e decisões de prazo. O número cinco sem esses fatos pode ser apenas uma promessa antiga.

Uma perda distribuída continua sendo perda

Ao entrelaçar, um pacote ausente produz apagamentos não consecutivos. O decodificador recebe fala válida entre eles e pode lidar melhor com esse desenho do que com uma sequência longa de apagamentos. Essa é a vantagem prevista.

O erasure frame tem zero bits e avança o estado do decodificador por um quadro de 20 milissegundos. Ele não recupera o conteúdo original. O null frame, também sem bits, representa ausência de saída do codec e normalmente não é transmitido. Juntar os dois numa categoria de “silêncio” apaga a causalidade.

O relatório deve manter o mapa de posições apagadas e relacioná-lo à avaliação posterior. Um serviço que continuou tocando áudio pode ter perdido justamente o dígito, nome ou comando que importava.

O pacote atrasado cruza vários prazos

Como um pacote entrelaçado carrega posições separadas no tempo, pode chegar tarde para a primeira e cedo para as últimas. Descartá-lo inteiro simplifica o código, mas elimina material aproveitável. Esperá-lo para salvar a primeira posição aumenta latência. Usar apenas o que ainda é oportuno requer prazo e destino por quadro.

Essa política não vem pronta no cabeçalho. Buffer de jitter, agendamento, interface do decoder e objetivo de serviço decidem localmente. O recibo útil declara chegada T, posição F1 expirada e substituída, F2 e F3 aceitas, ocupação do buffer e versão da política.

Contar o pacote como “recebido” superestima o uso; contá-lo como “perdido” apaga o salvamento parcial. A unidade correta depende da pergunta operacional.

Header-Free escolhe tempo em vez de amortização

O formato Header-Free transporta um quadro sem ToC e sem cabeçalho de interleaving. Ele não agrupa nem espalha. Paga mais cabeçalhos RTP, UDP e IP por segundo, mas evita esperar pela formação do grupo e simplifica o caminho ao decoder.

RFC 3558 recomenda LLL zero ou Header-Free quando a interatividade domina. Valores quatro ou cinco podem fazer sentido quando resistência a perdas é mais importante que atraso. A comparação precisa declarar qual recurso é escasso: banda, memória, tempo de diálogo ou tolerância a rajadas.

RFC 2508 e RFC 3095 mostram que compressão de cabeçalhos pode mudar o custo de pacotes pequenos. Suporte teórico não prova que o contexto de compressão ficou sincronizado na rota observada.

Mode Request não é confirmação

O campo Mode Request pede um modo ao codificador do sentido contrário. Em sessão um a um, o par é recomendado a atendê-lo; em multiparte, deve ignorá-lo. A repetição reduz a chance de a solicitação sumir com um único pacote.

Repetição não é reconhecimento. Registrar separadamente intenção, tentativas, recebimento, decisão do codificador e primeiro quadro sob o modo resultante. Marcar a mudança como concluída no envio cria sucesso sem evidência.

A mesma separação vale para interleaving: capacidade anunciada, configuração escolhida e fluxo observado são eventos diferentes.

Apagamentos iguais podem ter causas diferentes

O ToC descreve tipo e tamanho de cada quadro. Combinações inválidas de LLL, NNN, contagem ou bytes podem levar ao descarte e à inserção de apagamentos. O resultado temporal parece perda de rede, porém o responsável pode ser o empacotador ou o validador.

Separar nunca recebido, recebido tarde, carga inválida, tipo incompatível e evicção local. Uma métrica genérica de perda transfere o problema para a equipe errada.

RFC 4788 atualizou depois a família com EVRC-B, Compact Bundled, DTX e detalhes de registro e oferta/resposta. É contexto posterior. Não prova que um fluxo RFC 3558 adotou esses recursos.

Limite da evidência

Este Artigo não identifica operadora, equipamento, chamada, usuário, incidente, taxa medida, memória reservada ou resultado de escuta. Os exemplos derivam do mecanismo do padrão, não de uma implantação.

RFC 3550 e RFC 3551 enquadram RTP. RFC 3264 trata de oferta e resposta; RFC 2327 era o contexto SDP na publicação e RFC 8866 é contexto posterior. RFC 2508 e RFC 3095 descrevem compressão. RFC 8174 esclarece linguagem normativa. RFC 4788 é atualização explicitamente delimitada.

Running-Code Primacy e Minimum Initial Specification, de Heng Lu, são lentes editoriais declaradas. Elas orientam separar capacidade escrita de comportamento executado e manter a fronteira comum menor que decisões locais futuras. Não são evidência da intenção histórica dos autores nem de evento de rede.

A conclusão delimitada é esta: maxptime contém duração dentro do pacote; maxinterleave contém a dispersão entre pacotes. RFC 3558 permite trocar uma lacuna contínua por apagamentos separados, mas só recibos operacionais mostram se memória e tempo pagaram a troca.

Sources