Resumo

  • O SSRC identificava um espaço de sequência e tempo dentro de uma sessão RTP; não era uma identidade global nem permanente do participante.
  • Ao encontrar seu próprio valor em outra fonte, o emissor enviava RTCP BYE para o SSRC antigo, sorteava um candidato e verificava se já estava em uso.
  • O mesmo valor em novo endereço também podia resultar de loop, NAT, reinício de tradutor ou mobilidade; o CNAME ajudava a manter continuidade sem provar autoria.

A tabela via primeiro o conflito, não a causa

Para reproduzir mídia, o receptor agrupa por SSRC os números de sequência, timestamps, relatórios e estado de jitter. Duas origens independentes sob o mesmo valor podem parecer uma única fonte com saltos impossíveis. A colisão ameaça o significado da série, não apenas a elegância do cabeçalho.

O RFC 1889 escolheu um identificador de 32 bits que não dependia do endereço de rede. Isso permitia trabalhar com multicast, tradutores e mixers sem consultar um distribuidor central. Cada fonte sorteava um SSRC destinado a ser único na sessão RTP.

Essa autonomia vinha com uma obrigação: todo participante precisava reconhecer a rara coincidência e saber sair dela.

Um bom sorteio reduzia, mas não revogava, a possibilidade

O RFC 3550 estima cerca de 10^-4 de chance de ao menos uma colisão quando mil fontes começam juntas. Para uma nova fonte diante de mil valores já únicos, o exemplo cai para aproximadamente 2×10^-7. As contas não medem chamadas reais.

Usar o endereço IP local falha em redes privadas, através de tradutores e com várias fontes na mesma máquina. Chamar um gerador sem inicialização cuidadosa pode repetir a sequência em processos simultâneos. Antes do primeiro envio, uma fonte também pode ouvir os SSRCs presentes e rejeitar um candidato conhecido.

O desenho não apostou tudo no espaço de 32 bits. A recuperação continuou obrigatória.

BYE encerrava uma chave de sincronização

Ao detectar que outra fonte usa seu SSRC, o participante envia RTCP BYE pelo valor antigo. Em seguida, sorteia outro e consulta a tabela de fontes; se o candidato já existir, sorteia novamente.

Nada exige que a produção de áudio ou vídeo termine. O RFC 7656 esclarece que um fluxo RTP tem um SSRC em cada instante, mas o identificador pode mudar ao longo do tempo, inclusive por colisão.

Uma plataforma que trata SSRC como pessoa inventa uma saída e uma entrada. Um gravador que usa o número como chave definitiva quebra uma só sessão de mídia. O BYE informa o fim do rótulo antigo, não a morte de toda relação que o cercava.

Manter uma fonte era uma decisão local e provisória

Quando dois terceiros colidem, o receptor pode manter os pacotes de um e descartar os do outro se endereços de transporte ou CNAMEs permitirem separá-los. Cabe às fontes mudar o identificador.

Preservar a entrada já estabelecida evita misturar relógios, mas não concede propriedade sobre o número. A chegada de BYE ou o vencimento do estado muda o quadro.

A implementação guarda os primeiros endereços RTP e RTCP separadamente, pois as portas UDP de origem podem diferir. Depois de um mixer, o endereço comum talvez esconda a origem; CNAMEs diferentes em chunks SDES com o mesmo SSRC ainda revelam a incompatibilidade.

A volta de um pacote imitava uma segunda fonte

Um loop de encaminhamento entrega o mesmo SSRC por outro endereço. O receptor vê a mesma forma de uma colisão aleatória.

Por isso, o algoritmo mantém uma lista temporizada de endereços conflitantes. Ao encontrar o próprio SSRC, a fonte muda de valor uma vez e anota o caminho. Se o pacote refletido continuar chegando daquele endereço, ela o ignora. Renomear em cada volta faria o loop produzir uma sequência sem fim de BYE.

Mixers e tradutores precisam interromper loops. O RFC 7667 delimita a capacidade: a detecção depende da preservação correta de SSRC e CSRC. Sessões independentes interligadas e certas topologias de comutação retiram do RTP essa visão comum.

Mobilidade e NAT mudavam o valor probatório do endereço

O RFC 3550 deixou de exigir novo SSRC em toda mudança de endereço. Aplicações móveis podem aceitar o mesmo fluxo em novo caminho, desde que evitem alternância oportunista entre duas origens realmente conflitantes.

Um tradutor reiniciado que troca a porta UDP pode fazer todas as fontes encaminhadas parecerem retornos em loop. O RFC 5135 mostra como um mapeamento NAT expirado associa novo IP ou porta ao SSRC antigo e aciona detecção, com efeitos em diagnóstico e buffer de jitter.

O evento exige classificação. Ele não prova ataque, duplicação intencional nem culpa de um equipamento específico.

O CNAME ocupava outra camada de continuidade

Segundo o RFC 7022, o SSRC pode mudar por colisão ou reinício, enquanto o CNAME RTCP pode permanecer para vincular um endpoint e fluxos relacionados. Persistência longa ajuda monitoramento; um valor por sessão reduz correlação entre sessões.

Nenhuma opção autentica a pessoa. Participantes escolhem o CNAME e podem imitar outro valor. Ele é uma ligação operacional, não uma credencial.

Nem a sinalização moderna fecha o espaço. O RFC 8834 mantém obrigatória a atribuição aleatória e a resolução do RFC 3550 em WebRTC. Novos valores podem ser usados antes de confirmação, e funções auxiliares, como retransmissão, criam SSRCs não anunciados.

Fontes e limites

O mecanismo nasce no RFC 1889 e amadurece no RFC 3550. O RFC 5135 cobre NAT; o RFC 7022, CNAME; o RFC 7656, semântica do fluxo; o RFC 7667, topologia; e o RFC 8834, WebRTC. Eles não fornecem taxa atual de colisão, conformidade de produto, identidade humana, autenticidade da mídia ou garantia de reprodução.