Resumo

  • O parâmetro rport permite ao cliente pedir que a resposta SIP volte à origem IP e UDP efetivamente observada pelo servidor. A entrega comprova aquele retorno enquanto o mapeamento existe, não uma rota para o futuro.
  • Tupla, mapeamento, fluxo, registro, transação, diálogo e resultado pertencem a relógios e autoridades distintos. Um único indicador de “alcançável” não consegue explicar qual deles expirou.

O telefone envia um INVITE. Ao atravessar o tradutor, tanto o endereço quanto a porta de origem mudam. O proxy responde pelo mesmo caminho e o aparelho recebe a mensagem. Naquele instante, há um fato sólido: uma resposta cruzou a abertura que a requisição acabara de criar.

O problema começa quando esse fato é salvo como cadastro. Um minuto depois, outra requisição usa o mesmo par público, mas sai de outro nó ou encontra a tabela já limpa. O pacote some. A primeira entrega continua verdadeira; apenas nunca prometeu a segunda.

Publicada em agosto de 2003 na trilha Standards Track, RFC 3581 separa com precisão a correção estreita de roteamento e o uso mais ambicioso da informação como endereço. É uma lição sobre validade temporal: o valor pode estar correto sem ter competência para durar.

A regra anterior montava um destino híbrido

No SIP sobre UDP, a resposta original combinava a origem IP do datagrama recebido com a porta declarada em sent-by no Via superior. A escolha ajudava servidores a concentrar mensagens em um ponto de escuta. Quando um NAT mudava também a porta, contudo, a combinação passava a juntar o endereço externo visto na rede com uma porta interna anunciada pelo agente.

O cliente coloca rport sem valor no Via. O vazio é deliberado: não existe afirmação de que o cliente conheça a porta pública. Ele solicita que o receptor preencha a observação. O servidor insere a porta em rport e o endereço em received, mesmo que este último coincida com sent-by.

Em transporte unicast não confiável, sem maddr, a resposta vai a received:rport. Ela também precisa sair do mesmo endereço e porta do servidor que receberam a requisição. Para NAT simétrico, o lado remoto integra a chave do mapeamento.

Portanto, a regra não autentica o cabeçalho nem cria um endpoint. Ela vincula uma resposta ao que foi visto no fio para uma transação definida.

Uma tupla precisa carregar seu observador

Imagine Via com 10.1.1.1:4540 e origem observada 192.0.2.1:9988. A segunda tupla pode ser o destino exato da resposta. Não é o nome do usuário, a identidade da instância ou um direito permanente sobre a porta.

Há três degraus de evidência. rport vazio mostra que o remetente pediu o comportamento. O número devolvido mostra o que o servidor registrou. Só o recebimento no cliente confirma que a resposta completou o percurso. Mesmo o último recibo não informa por quanto tempo a abertura ficará ativa ou quais outros remetentes serão aceitos.

Um registro sério junta branch, Call-ID, CSeq, Via antes e depois, origem de rede, instância e interface de entrada, socket de saída, status da resposta e confirmação no cliente. Salvar somente reachable=true elimina o tempo, o objeto e o observador da afirmação.

O proxy sem estado ainda precisa de memória portátil

Um servidor que escuta em vários endereços deve responder pelo exato socket de entrada. Proxy stateful guarda isso durante a transação. Proxy stateless pode codificar endereço e porta no Via que acrescenta e recuperar a decisão quando a resposta volta.

Não há ausência de proveniência; há mudança do local em que ela reside. Se a telemetria reduz tudo ao nome lógico do proxy, deixa de provar qual interface participou. Isso é perigoso em cluster: dois nós podem ser equivalentes para o balanceador e diferentes para o NAT.

Capacidade do serviço, saúde de uma instância e continuidade desta rota são métricas separadas. Substituir a terceira pela primeira produz failover verde no painel e pacote preto no fio.

O mapeamento tem um relógio próprio

RFC 3581 afirma que o binding precisa durar até o fim da transação. Transações não INVITE costumavam ser menores que tempos UDP comuns. INVITE pode esperar indefinidamente pela resposta final; por isso o texto recomenda retransmitir periodicamente mesmo depois de resposta provisória.

A retransmissão existe porque a tupla não contém vencimento. Silêncio, reinicialização, troca de política ou failover podem fechar a porta sem alterar o registro SIP. Uma resposta provisória não concede um lease.

O documento recorria ao algoritmo de descoberta de vida da RFC 3489 e já alertava que ele não era confiável. RFC 5389 tornou RFC 3489 obsoleta; RFC 8489 depois substituiu RFC 5389. O operador não pode converter estimativas históricas em certeza atual. Deve medir último tráfego, orçamento, cadência e incerteza.

Copiar a porta para Contact copia o valor, não as condições

received e rport revelam o endereço externo visto pelo servidor. Usá-lo em Contact ou Record-Route parece oferecer uma volta fácil para pedidos futuros. RFC 3581 chama essa extensão de UNSAF e registra suas fragilidades.

O mapeamento pode exigir re-registros quase cem vezes mais frequentes que o ciclo normal. Em NAT simétrico, o endereço aceita tráfego somente do servidor original. Outro membro do cluster pode ler o mesmo Contact e falhar. Se um proxy recebeu REGISTER antes do registrar, futuras requisições precisam atravessá-lo; Path, na RFC 3327, declara essa obrigação.

A porta sozinha não traz validade, peer permitido, proxy responsável ou afinidade. Ela é um resultado de observação sem seu envelope causal.

A estratégia de saída do próprio RFC pede uma forma de reutilizar conexão ou fluxo iniciado pelo cliente, tratar clusters e não aumentar carga. RFC 5626 definiu SIP Outbound, vinculando registros a fluxos, permitindo redundância e oferecendo keepalive e detecção de falha. RFC 6314 recomenda essa prática.

Ainda assim, conceitos não se fundem. RFC 6223 negocia keepalive e diz que isso não define connection reuse. RFC 5923 cuida de pedidos reversos em transportes conectados. RFC 5627 oferece GRUU estável para uma instância. Pong não escolhe registro; flow token não autoriza; URI estável não prova toque, atendimento ou mídia.

Proteger a sinalização não prolonga a abertura

Endereço e porta observados podem ser sensíveis. RFC 3581 aponta SIP sobre TLS para proteger sinalização. Em TCP/TLS, rport é principalmente informação sobre a porta vista, não mecanismo necessário para a resposta UDP atravessar NAT.

Um intermediário que remove rport pode causar negação de serviço. Integridade impede a alteração, mas não prova controle sobre a porta pública nem mantém o binding. O registro IANA coordena o nome do parâmetro; não atesta suporte, operação ou entrega.

O modelo correto conserva recibos independentes: autenticação de identidade; observação da tupla; socket do proxy; Path ou fluxo; escolha do registrar; Route set; e, por fim, toque, atendimento, mídia e resultado da aplicação. Nenhum recibo pode falar pelo seguinte.

Limite da evidência

Este Artigo não identifica operadora, PBX, provedor SIP, agente, proxy, registrar, NAT, cluster, usuário, chamada, incidente ou resultado de mídia. Standards Track não prova adoção.

RFC 3261 fornece a base de Via e transação; RFC 3327, Path; RFC 3424, o enquadramento UNSAF. RFC 3489 é apenas contexto histórico; RFC 5389 e RFC 8489 registram evolução do STUN. RFC 5626, RFC 6314, RFC 5923, RFC 6223 e RFC 5627 separam Outbound, prática NAT, reutilização, keepalive e identidade roteável. IANA não substitui running code.

Running-Code Primacy e Minimum Initial Specification, de Heng Lu, são lentes editoriais declaradas. Servem para testar o caminho real e limitar a regra comum ao necessário. Não são prova da intenção dos autores ou de implantação.

O limite final é simples: uma resposta encontrou uma porta em determinado momento. O recibo merece ser guardado. A porta, porém, não virou endereço permanente.

Fontes