Resumo

  • O RFC 5346 relata um ensaio pré-comercial de Infrastructure ENUM realizado na Coreia em 2006. Suas médias de atraso até o 200 OK sugeriram impacto pequeno para o chamador, mas não trouxeram contagens, percentis, denominadores de falha, estado de cache nem a proveniência da rota de cada chamada.
  • A política do ensaio distinguia estados que um painel agregado poderia misturar: NOERROR com URI utilizável continuava no caminho ENUM; NOERROR sem URI utilizável encerrava imediatamente uma chamada para faixa exclusiva ENUM; NXDOMAIN, outras falhas de DNS e timeout devolviam a decisão ao método específico do fabricante e, em geral, à PSTN.
  • Uma operação auditável precisa registrar cada transição — número E.164, resposta DNS, NAPTR escolhida ou rejeitada, origem do mapeamento de domínio, motivo do fallback, acordo de interconexão, gateway executado e desfecho — em vez de inferir autoridade a partir de uma chamada completada.

O número médio apagou a bifurcação que importava

A tabela do RFC 5346 compara o tempo médio entre o envio de um SIP INVITE e a chegada do 200 OK. Para a operadora A chamando a si própria, os valores foram 2,33 segundos com ENUM e 2,28 sem ENUM. De A para B, 2,23 contra 2,25. De A para outro destino PSTN, 4,11 contra 3,79. As três combinações iniciadas pela operadora B ficaram em 2,18 contra 2,05, 2,19 contra 2,19 e 3,95 contra 3,41 segundos.

Esses pares sustentam uma afirmação modesta: naquele ensaio e naquelas combinações, a diferença média de iniciação provavelmente não seria perceptível como degradação relevante pelo usuário. Eles não sustentam a afirmação de que ENUM forneceu a rota, de que a resolução funcionou em todas as tentativas ou de que a arquitetura estava pronta para uma implantação comercial universal.

Uma chamada rápida podia ter seguido uma NAPTR válida, resolvido seu domínio e alcançado um gateway IP. Outra chamada igualmente rápida podia ter esperado um timeout, acionado o método antigo do softswitch e chegado ao destino pela PSTN. Ao ocupar a mesma célula estatística, os dois percursos perdiam sua identidade operacional.

Também faltam no relato contagens de amostras, distribuição por percentis, caudas, taxa de falha, distinção entre cache quente e frio e a associação entre cada observação e sua rota efetivamente executada. A média não é falsa; é estreita. O erro surge quando se pede a ela que responda uma pergunta de autoridade que o desenho de medição não capturou.

NOERROR não significava “pode completar a chamada”

O ensaio reservou uma faixa de números “ENUM only”. Um número em serviço nessa faixa possuía URI SIP ou H.323 utilizável e não possuía ponto de interconexão PSTN. Um número fora de serviço podia manter o domínio ENUM existente sem oferecer uma URI válida para chamada.

Por isso, uma consulta NAPTR podia retornar RCODE=0 e ainda assim conduzir à interrupção imediata. Para aquele conjunto, enviar o número à PSTN seria inútil: a rota legada deliberadamente não existia. Dependendo da implementação, insistir em fallback também poderia introduzir repetição ou laço.

Já NXDOMAIN, erro de formato, falha do servidor, operação não implementada, recusa ou ausência de resposta acabavam tratados como erros de DNS e levavam ao método específico do fabricante. Para números comuns com interconexão PSTN, a ausência do novo diretório não equivalia à ausência do serviço telefônico.

Logo, o RCODE não continha sozinho a decisão. O mesmo sistema precisava conhecer a política da faixa, reconhecer os serviços NAPTR que suportava e saber se uma saída legada era permitida. DNS carregava evidência; a configuração da operadora lhe dava consequência.

O fallback preservou disponibilidade e removeu observabilidade

Fallback parece um verbo técnico neutro. Na prática, ele trocava a instituição que decidia o próximo salto. Antes da troca, o softswitch dependia da árvore e164.arpa, do resolvedor, do conjunto NAPTR, do enumservice aceito e da URI. Depois dela, dependia da tabela de prefixos do equipamento e da rede PSTN.

Uma métrica de conclusão recompensava as duas rotas do mesmo modo. Isso favorecia a continuidade, mas permitia que cobertura insuficiente, erro de provisionamento ou indisponibilidade do resolvedor permanecessem escondidos por trás do sistema antigo. Quanto melhor a PSTN resgatava chamadas, menos visível podia parecer o fracasso da migração.

Essa tensão aparece em muitas transições de infraestrutura. O mecanismo anterior serve de rede de segurança; então passa a ser usado como prova de que o mecanismo novo funciona. O que falta é um recibo da troca de autoridade.

No caso descrito pelo RFC, “ENUM tentado” também era uma classificação fraca. Uma consulta podia produzir URI válida e ainda assim não produzir rota. O domínio da URI precisava ser transformado em endereço de interconexão por outro mecanismo. A chamada só pertencia de fato ao caminho ENUM quando sobrevivia a essa segunda decisão.

Uma tabela privada carregava algo que a resolução pública não provava

O RFC 5346 descreve duas opções para mapear o domínio de uma URI. O softswitch podia usar DNS recursivo e as regras de localização SIP ou consultar uma tabela fixa privada que associava domínios a gateways. Se a tabela não conhecesse o domínio, ou se a resolução recursiva falhasse, o sistema podia retornar à PSTN.

A tabela fixa duplicava administração. Registros ENUM e mapeamentos locais precisavam permanecer coerentes. O documento a trata como expediente temporário, adotado porque havia poucos registros no ensaio e o serviço comercial existente não podia ser colocado em risco. Os equipamentos podiam alternar rapidamente entre a tabela e o DNS enquanto os operadores avaliavam desempenho e confiabilidade.

Mas a tabela também representava um acordo bilateral. Operadoras esperavam remuneração de interconexão e podiam concordar com um gateway específico, talvez inacessível de forma pública. A resolução de um nome não demonstrava que qualquer endereço retornado era uma interconexão autorizada para aquela parte.

Portanto, a tabela era simultaneamente um atalho técnico e uma sombra contratual. Uma entrada obsoleta podia continuar enviando tráfego a um gateway que o DNS já não indicava. Ignorar a tabela podia contornar a escolha comercial dos parceiros. Nenhum dos dois riscos aparece no tempo entre INVITE e 200 OK.

O timeout era a decisão de abandonar um regime

O período sem resposta não era apenas latência. Quando se esgotava, ENUM deixava de ser a autoridade da chamada. O relógio de estabelecimento somava espera do resolvedor, escolha de fallback, roteamento PSTN e resposta SIP, mas não identificava o instante em que o regime mudou.

O ensaio não resolveu isso simplesmente encurtando os timeouts do DNS. A pilha de resolução do softswitch servia também a outras funções; configurá-la de maneira não conforme sem estudar os efeitos colaterais foi rejeitado. Um ajuste local para acelerar fallback de ENUM poderia alterar consumidores de DNS que nada tinham a ver com ENUM.

Essa dependência ensina como observar o sistema. O operador precisa de tempos separados: início e término da consulta, expiração, decisão de fallback, seleção de gateway, emissão do INVITE subsequente e resposta final. Precisa também saber qual configuração de resolvedor e qual estado de cache estavam ativos.

O erratum mantido para futura atualização do RFC corrige quatro referências a “regra 2” que deveriam apontar para a regra 3 na seção 4.1.1. Outro troca “non-complaint” por “non-compliant”. Eles não mudam a política de roteamento, mas mostram por que um runbook operacional deve guardar a versão e os errata usados para interpretar uma árvore de decisão.

O sucesso visível terminava cedo demais

O 200 OK confirma uma etapa do estabelecimento SIP. Ele não confirma qualidade de mídia, duração da conversa, faturamento correto, legitimidade do destino ou propriedade atual do número. Tampouco identifica se o pacote final atravessou interconexão IP bilateral ou rede telefônica legada.

O limite do ensaio deve permanecer explícito. O RFC 5346 é Informational, não Internet Standard, e descreve experiência pré-comercial de 2006. O RFC 6116 posteriormente substituiu o RFC 3761 como especificação ENUM. O documento histórico não prova como uma operadora atual roteia chamadas nem prescreve uma meta universal de atraso.

Sua utilidade está em expor a topologia das decisões. Ele mostra que descobrir uma URI, localizar um domínio, possuir permissão de interconexão e completar uma chamada são eventos separáveis. Um painel pode escolher medi-los separadamente ou perdê-los para sempre.

Dados compartilhados deslocaram a responsabilidade pelo erro

O RFC observa que um dado ENUM provisionado incorretamente causa problema na rede da operadora que origina a chamada. Essa operadora pode não saber quem serve o número, quem publicou o registro ou quem tem autoridade para corrigi-lo. A portabilidade numérica agrava a incerteza.

O resolvedor pode responder fielmente ao registro existente. O softswitch pode processá-lo conforme suas regras. A chamada pode falhar na rede de origem. Mesmo assim, nenhum desses fatos revela o dono da reparação.

Um incidente precisa ligar a versão do registro, o canal de provisionamento, a visão do resolvedor, a afirmação de operadora responsável, o estado de portabilidade, a decisão de rota e um contato com poder de corrigir. Sem essa cadeia, compartilhar descoberta em escala também compartilha falhas, mas não distribui a capacidade de resolvê-las.

A visibilidade pública tinha custo próprio

Os dados de Infrastructure ENUM do ensaio foram disponibilizados pela Internet pública, oferecendo um ambiente realista para os resolvedores e facilitando compartilhamento. Algumas operadoras questionaram essa necessidade porque consultas ligadas a números telefônicos podiam revelar informação sensível; preferiam acesso privado em certos contextos.

O próprio resolvedor era parte da superfície de segurança. Um atacante capaz de comprometê-lo poderia atrasar ou impedir chamadas. O RFC recomenda restringir o acesso à rede local do softswitch e limitar o acesso externo.

Privacidade, validade e autorização são propriedades diferentes. Tornar o serviço privado reduz observadores, mas não torna seus registros corretos. Torná-lo público facilita auditoria e interoperabilidade, mas não autoriza automaticamente o uso de todo endpoint resolvido. O desenho de medição precisa registrar também a visão do resolvedor e o domínio de acesso, não apenas seu RCODE.

Um recibo de rota precisa sobreviver à agregação

O registro mínimo começa com o número E.164 normalizado e a faixa de política aplicável. Em seguida preserva pergunta e resposta DNS, RCODE, NAPTRs oferecidas, motivos de rejeição, ordem e preferência selecionadas, enumservice, URI e TTL. Depois identifica se o domínio foi mapeado por DNS ou tabela fixa, qual versão da tabela e qual gateway resultaram.

Se houve fallback, o recibo precisa nomear o gatilho, o instante, a rota legada permitida e a proteção contra laço. Por fim, separa o resultado SIP, a conectividade de mídia, a conclusão e o faturamento. O valor não está em produzir um log enorme, mas em impedir que a agregação desfaça a relação causal.

Só então uma média de atraso volta a ser interpretável. Ela pode ser dividida por rota realmente executada, por estado de cache, por classe de resposta e por destino. A organização passa a medir continuidade sem confundi-la com adoção, e desempenho sem usá-lo como substituto de autoridade.