Resumo

  • RFC 5118 publicou mensagens para exercitar implementações SIP com IPv6, mas declarou que não alterava normativamente o SIP e não tentava cobrir todos os casos válidos ou inválidos.
  • Uma URI com o porto dentro dos colchetes IPv6 pode ser bem formada e apontar para outro endereço; o erratum verificado esclarece que o valor vira o último par de octetos.
  • Um controle útil separa custódia dos bytes, regra gramatical, árvore do parser, intenção de host e porto, mensagem encaminhada, próximo salto, transação, diálogo, mídia e resultado.

O número 100% parecia definitivo porque o denominador estava escondido. Ele significava cem por cento de um conjunto publicado, em uma compilação, com uma configuração. Não significava cem por cento da gramática SIP, dos intermediários, dos caminhos IPv6 nem das chamadas reais.

RFC 5118 deixou essa limitação expressa. O documento é Informational. Não é normativo sobre SIP. Não cataloga todas as maneiras de construir uma mensagem inválida nem todas as formas válidas pouco usuais. Alguns exemplos pressionam apenas o parser; outros alcançam a aplicação.

Um caso aprovado podia carregar o destino errado

Considere sip:[2001:db8::10:5070]. Se a intenção era o host 2001:db8::10 no porto 5070, o colchete de fechamento veio tarde. A gramática incorpora 5070 ao literal IPv6. Não existe componente de porto para o parser recuperar.

O resultado pode ser sintaticamente válido. Semanticamente, não conduz ao destino desejado. O erratum 1311 corrige a descrição do RFC: o valor torna-se o último par de octetos IPv6, e não um único octeto.

A forma pretendida fecha o endereço antes do porto: sip:[2001:db8::10]:5070. Ambas podem produzir sucesso de análise; as árvores e os destinos são diferentes. O teste precisa guardar uma expectativa externa de host e porto e comparar a seleção de socket observada.

O corpus também contém uma URI IPv6 sem os colchetes obrigatórios, que deve receber 400. Portanto, a mensagem do RFC não é tolerância ilimitada. Ele distingue erro gramatical, construção válida mas semanticamente surpreendente e exceção de interoperabilidade.

A exceção received tinha uma direção

Em Via, RFC 3261 aplicava uma referência IPv6 com colchetes a sent-by, mas uma direção IPv6 nua ao parâmetro received. Testes de interoperabilidade encontraram implementações divididas: algumas aceitavam ou emitiam colchetes nesse parâmetro.

RFC 5118 recomenda receber as duas formas, mas enviar sem colchetes. É uma política assimétrica: tolerância na borda de entrada e forma canônica na saída. O campo, a razão e o comportamento estão nomeados.

Transformar essa regra em um removedor global de colchetes danificaria URIs SIP. Transformá-la em rejeição estrita de todo valor legado quebraria pares conhecidos. A implementação deve registrar quando acionou a exceção, que valor estruturado obteve e o que transmitiu.

O cabeçalho não manda no SDP

Um literal IPv6 em URI SIP usa colchetes. Uma direção de conexão no corpo SDP não. O RFC apresenta mensagens com IPv4 e IPv6 em diferentes campos Via, famílias distintas em linhas de áudio e vídeo e endereços IPv4 mapeados em IPv6 na sinalização e no SDP.

Uma camada que padroniza aparência sem conhecer o campo pode criar erros. O contexto gramatical é parte do dado. Retirá-lo para produzir uma coluna única chamada “endereço” simplifica o painel e empobrece a prova.

O documento discute ainda um caminho de ABNF capaz de admitir um cólon extra antes de uma parte IPv4 incorporada. Um receptor pode aceitar por robustez; se encaminhar, deve remover o cólon. Aceitar a entrada e custodiar a saída são obrigações separadas.

O arquivo exato impedia um teste imaginário

Linhas SIP extensas precisavam ser dobradas no formato do RFC. A convenção allOneLine, herdada do RFC 4475, instrui como reconstruí-las. RFC 5118 inclui também um arquivo codificado com as mensagens em representação exata.

Copiar da página pode introduzir espaços, alterar quebras ou desalinhar Content-Length. Um harness que “arruma” o texto antes do parser testa outra entrada. Por isso, origem, método de extração, bytes, tamanho e hash vêm antes do resultado.

O hash da fixture torna a comparação repetível; não torna a conclusão universal. A compilação, a biblioteca e a configuração também precisam ser identificadas. Uma atualização que mantém o exit code mas muda a árvore pode alterar o próximo salto.

A chamada começa onde o parser termina

Depois da árvore vem a política de resolução e roteamento. Depois, o salto remoto aceita ou rejeita a mensagem. A transação pode ou não receber resposta. Um diálogo pode surgir, mas o SDP pode indicar mídia inalcançável. Pacotes podem chegar sem que o objetivo do usuário seja cumprido.

Cada fase exige recibo próprio. Também não se pode usar uma chamada bem-sucedida para provar que todos os parsers concordaram: um Contact alternativo, uma reescrita anterior ou um fallback pode ter escondido a diferença.

A sequência mínima é: bytes; produção; árvore; intenção; saída; próximo salto; transação; diálogo; mídia; resultado. “IPv6 suportado” não substitui essa cadeia.

O denominador deve aparecer no conselho

Um placar precisa mostrar quantos casos, quais categorias, quais versões e quais camadas foram testadas. Caso contrário, o percentual vira uma autoridade sem escopo. O fornecedor ganha uma alegação simples; o operador recebe o risco residual sem nome.

RFC 5118 deve ser usado como mapa de costuras. Ele localiza onde a realidade muda de forma: página para fio, endereço para porto, entrada tolerada para saída canônica, cabeçalho para corpo, parser para aplicação. É aí que o monitoramento deve conservar a diferença, não escondê-la.

Fontes