Resumo

  • RFC 3605 criou o atributo de mídia a=rtcp para declarar uma porta e, opcionalmente, um endereço de controle quando o NAT destrói a antiga relação de portas consecutivas entre RTP e RTCP.
  • A observação feita por STUN tem observador, destino e tempo. Inserir o tuple no SDP não garante que outro par verá o mesmo mapeamento, que ele continuará ativo ou que um relatório válido chegará.

O registro operacional parecia completo: havia uma resposta STUN, uma linha SDP e um status de negociação positivo. Quando a equipe procurou os relatórios de recepção, encontrou uma lacuna. O erro não estava necessariamente em qualquer um dos três registros. Estava no verbo escolhido para uni-los. “Observado” virou “reservado”; “anunciado” virou “alcançável”; “negociado” virou “recebido”.

RFC 3605 foi publicado em outubro de 2003 na Standards Track para corrigir uma limitação específica de descrição. RTP e RTCP costumavam ocupar duas portas UDP relacionadas: a mídia em uma porta par e o controle na porta ímpar seguinte. O SDP informava a porta de mídia e deixava a aplicação derivar a outra.

Um NAT que remapeia portas pode desfazer tanto a sequência quanto a paridade. Se o equipamento também usa um conjunto de endereços públicos, os dois fluxos podem aparecer em endereços distintos. Somar um ao número externo da mídia deixa de ser regra e passa a ser palpite.

A extensão permite escrever a=rtcp: com a porta e, opcionalmente, tipo de rede, tipo de endereço e endereço de conexão. É um atributo de nível de mídia e não deve ser usado no nível da sessão. Assim, o destino de controle traduzido pode ser comunicado sem alterar a linha principal de mídia.

O ganho é de representação. A linha informa o que o gerador acredita ser a coordenada correta. O parser comprova que entendeu a forma. A negociação registra o que as partes aceitaram. Nenhum desses fatos abre uma porta, mantém uma entrada NAT ou entrega um datagrama.

O próprio RFC mostra a descoberta por STUN como uma sequência: reservar duas portas locais; enviar de cada uma para um servidor; deixar o servidor ler os endereços e portas de origem; receber esses valores na resposta. Só então o host conhece os tuples externos vistos por aquele servidor.

Há uma condição expressa: o procedimento pressupõe que o NAT utilize a mesma tradução para o terceiro que respondeu e para o par descrito no SDP. O texto diz que não existe garantia de que todos os NATs implantados tenham essa característica. Essa frase impede que a resposta STUN seja promovida a verdade universal.

Uma observação precisa viajar com seu escopo. Servidor observador, horário, socket local, interface, protocolo, tuple externo, destino pretendido e idade da observação pertencem ao mesmo registro. Se apenas o endereço e a porta forem preservados, uma verdade temporária se transforma em configuração sem procedência.

O tempo é especialmente importante. O mapeamento pode expirar entre a observação e o primeiro pacote RTCP. Uma mudança de rede pode manter a sessão de sinalização enquanto troca a interface de mídia. Um failover pode mover a aplicação para um host sem o estado anterior. O texto SDP permanece idêntico enquanto a realidade operacional muda.

RFC 3605 também escolheu uma forma de compatibilidade que admite falha parcial. Alterar a linha de mídia poderia levar aplicações antigas a rejeitar toda a descrição. Um atributo desconhecido pode ser ignorado. A aplicação antiga talvez continue recebendo RTP, mas deixe de enviar RTCP ao destino explícito. A mídia sobrevive e a confirmação desaparece.

Isso torna enganoso o indicador “sessão ativa”. Ele pode agregar mídia recebida, sinalização estabelecida e porta de controle anunciada sem ter um único pacote de feedback validado. A organização deve conservar os estados separados para não usar disponibilidade do áudio como substituto de observabilidade.

Depois da descoberta e da descrição ainda vem a cadeia de entrega. Um contador no processo mostra uma tentativa de envio. Uma captura no host mostra passagem por uma interface. Uma captura no lado remoto prova chegada àquele ponto. O receptor precisa validar o pacote RTCP e associá-lo à sessão. A coleta precisa armazená-lo sem perder fonte e intervalo.

O relatório validado continua sendo uma evidência limitada. RFC 3550 atribui ao RTCP feedback de recepção, identificação, sincronização e outras funções de controle. Seus números pertencem a fontes e janelas específicas. Não demonstram, por si, identidade humana, autorização do destino, experiência perfeita ou resultado comercial.

Já o silêncio é uma hipótese aberta. O par pode ignorar a=rtcp, enviar para a porta adjacente, escolher multiplexação, perder o mapeamento, encontrar um filtro, ainda não atingir o intervalo de relatório ou produzir dados que a telemetria não ingere. Zero linhas numa tabela não é relatório de zero perda.

RFC 5761 permite negociar RTP e RTCP na mesma porta. RFC 8859 mantém rtcp como atributo de transporte em sua análise de multiplexação, e o registro IANA continua publicando a entrada de nível de mídia. A escolha vigente deve ser registrada no momento da negociação; um default de software não pode reconstruí-la depois.

RFC 5389 reposicionou STUN como ferramenta, e não como solução integral de travessia. A diferença importa para governança. Uma ferramenta pode produzir um fato útil sem ganhar autoridade sobre o resultado final. A resposta de descoberta informa. O SDP coordena. O socket executa. A rede entrega. O RTCP reporta. A análise decide.

Integridade de sinalização fecha outra pergunta. RFC 3605 reconhece que reescrever SDP pode redirecionar a parcela RTCP e discute proteção extremo a extremo. Se a verificação passa, aumenta a confiança sobre autoria e integridade da declaração. Não aumenta automaticamente a vida do mapeamento e não confirma autorização para receber dados de controle.

O modelo de evidência adequado começa pelo SDP original e seu hash. Depois registra parser, resultado de oferta/resposta e modo de portas. Liga socket e processo à versão. Preserva a observação STUN com tempo. Registra o tuple anunciado e a verificação de integridade. Em seguida grava primeiro envio, primeira chegada remota, primeiro pacote válido, primeiro relatório, período coberto, ingestão e decisão.

Essa sequência permite tratar ausência como ausência. Se o último recibo é a observação STUN, não se inventa entrega. Se há captura remota, mas nenhuma métrica, o problema muda de rede para ingestão. Se o relatório chegou e nenhuma ação ocorreu, a proveniência da decisão pode ser auditada.

A lição não é abandonar o atributo. O registro IANA e os RFCs posteriores mostram que ele permanece parte da linguagem SDP. A lição é conservar o tamanho da promessa. RFC 3605 tornou uma coordenada expressável depois do NAT. Só o código em execução pode transformar essa coordenada em caminho comprovado.