Resumo

  • EVRCWB1 prende toda a sessão a uma taxa e a um modo fixos. Uma atualização SDP só legitima outra configuração se houver evidência de um novo limite de sessão ou payload.
  • mode-set-recv e recvmode continuam sendo preferências, não comandos. sendmode é uma declaração do emissor e pode chegar depois da mídia; nenhum deles substitui o recibo das tramas.

O analisador encontrou duas descrições corretas. A primeira dizia modo 0; a segunda, modo 4. Como ambas eram sintaticamente válidas, o relatório encerrou a ocorrência como renegociação normal.

Os pacotes pertenciam ao mesmo EVRCWB1, sob a mesma identidade de sessão e o mesmo payload binding. O erro não estava em cada fotografia isolada. Estava na continuidade entre elas.

A regra fixa depende da identidade

EVRCWB1 é o formato compact bundled de taxa única. A RFC 5188 determina que a sessão inteira mantenha a mesma taxa fixa e o mesmo modo: 0 para wideband ou 4/7 para narrowband conforme a configuração permitida.

Isso transforma a identidade da sessão em parte da regra. Para mudar legitimamente, o operador precisa demonstrar onde terminou o intervalo anterior, qual nova sessão ou novo vínculo começou e a que configuração cada pacote pertence.

Uma SDP posterior não retroage sobre pacotes antigos. Sem o corte verificável, duas configurações válidas não formam automaticamente uma transição válida. E, se o sistema troca o identificador apenas no banco sem alterar o fluxo executável, o novo rótulo também não resolve a violação.

Preferência ainda não é autoridade

mode-set-recv permite que um receptor EVRC-WB informe ao emissor remoto o conjunto de modos que prefere. Para EVRC-B, recvmode informa um modo preferido. Ambos são parâmetros receive-only.

O emissor remoto pode ignorar a preferência e continuar conforme. O receptor deve conseguir decodificar mesmo quando o modo escolhido fica fora da lista preferida. Portanto, ver mode-set-recv=4 não prova que o codificador passou a 4.

Essa liberdade não revoga a regra fixa de EVRCWB1. Ela apenas separa duas perguntas. A primeira é quem pode escolher o modo. A segunda é se o modo escolhido permaneceu invariável dentro da sessão. Um pedido não responde à primeira; uma SDP isolada não responde à segunda.

Sendmode descreve, mas não cronometra sozinho

sendmode informa o modo corrente do codificador do emissor. A RFC 5188 também alerta que a mídia RTP pode chegar bem antes da SDP inicial ou atualizada que contém essa declaração.

Quando o codificador muda em T1, os pacotes podem chegar em T2 e a atualização em T3. Até T3, o último estado documental está velho. Depois de T3, a nova linha ainda não atribui automaticamente um modo a cada pacote anterior.

É necessário preservar a versão offer/answer, o instante da transição do codificador, sequence e timestamp RTP, envio, chegada e ingestão pelo decoder. A divergência pode ser atraso de controle, captura incompleta ou mudança indevida. O tempo decide qual hipótese permanece.

Direção evita declarações sem dono

mode-set-recv e recvmode são receive-only; sendmode é send-only. O primeiro não é útil em um stream sendonly, e o segundo não é útil em um stream recvonly.

Middleboxes que copiam todos os parâmetros para as duas direções criam simetria visual e perdem o proprietário da afirmação. O recibo deve guardar endpoint, direção, payload e versão, não apenas a cadeia modo=valor.

Parâmetros desconhecidos em uma oferta devem ser ignorados e não reaparecer na resposta. Ecoar um campo que o endpoint não compreende fabricaria concordância sem semântica compartilhada.

Codec e clock não provam o modo executado

Os subtipos audio/EVRCWB, EVRCWB0 e EVRCWB1 escolhem os formatos interleaved/bundled, header-free e compact bundled. Eles dizem como analisar o payload, não qual modo cada trama usou.

Os modos 4 e 7 do EVRC-WB interoperam com EVRC-B. Por isso uma oferta EVRC-WB deve anunciar também EVRC-B como alternativa para peers antigos. O codec selecionado, a preferência do receptor e o modo do emissor continuam independentes.

O clock RTP é sempre 16 kHz, ainda que a entrada do encoder ou a saída do decoder seja 8 kHz. O valor 16000 mede timestamps; não é recibo da captura acústica nem da qualidade entregue.

Legacy não é falha por ausência

A RFC 5188 adiciona recvmode e sendmode aos registros EVRC-B da RFC 4788. Implementações antigas não enviam esses campos e os ignoram se os recebem. A chamada pode continuar interoperável.

Ausência pode significar peer legacy, atributo opcional omitido, normalização intermediária ou versão SDP perdida. Converter ausência em modo 0 ou rejeição elimina a incerteza sem evidência.

O registro deve preservar capability/version, campos brutos e tratamento de extensões. Só então a falta de atributo pode ser classificada como compatibilidade esperada, perda operacional ou desconhecido.

O recibo que fecha a continuidade

Comece com ID imutável de sessão e mudança, papéis, direções, versões da oferta e resposta, payloads oferecidos e escolhidos, subtipo, clock e linhas rtpmap, fmtp, ptime e maxptime.

Registre preferência e proprietário, decisão do emissor de respeitar ou não, cada sendmode com horário, transições reais do codificador e as tramas correspondentes. Para EVRCWB1, inclua o início e o fim do vínculo fixo e qualquer nova identidade que autorize outra configuração.

Feche com aceitação do decoder, saída e resultado da aplicação. Decodificar não prova preferência; preferência satisfeita não prova qualidade. O formato não fala pela experiência.

Decisão de liderança

Não aprove mudanças observando apenas documentos válidos. Exija a fronteira que transforma duas configurações em dois intervalos autorizados.

Preservar sessão, direção e tempo impede que flexibilidade vire descontrole. Também evita o erro oposto: tratar uma escolha permitida do emissor como desobediência porque um receptor havia escrito outra preferência.

Fontes

  1. RFC 5188 HTML
  2. RFC 5188 texto
  3. Informações RFC 5188
  4. Datatracker RFC 5188
  5. Histórico RFC 5188
  6. Referências RFC 5188
  7. Errata RFC 5188
  8. RFC 4788
  9. Informações RFC 4788
  10. RFC 3558
  11. Informações RFC 3558
  12. RFC 3264 oferta-resposta
  13. Informações RFC 3264
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. IANA audio/EVRCWB
  17. Parâmetros RTP da IANA
  18. Heng Lu — camadas de realidade
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — prioridade ao código em execução