Summary

  • RTP grouped one timing and sequence-number space under a randomly chosen 32-bit SSRC, but scoped that identifier to one RTP session rather than making it a permanent participant identity.
  • A source that detected its own SSRC in use sent RTCP BYE for the old value, checked a new random candidate against known sources and continued under the replacement.
  • The same SSRC arriving from another transport address could mean collision, loop, NAT rebinding, translator restart or mobility; CNAME and topology evidence narrowed the diagnosis without authenticating an owner.

One number had begun grouping two incompatible histories

A receiver uses the Synchronization Source identifier to decide which RTP packets belong to one timing and sequence-number space. If two independent senders choose the same SSRC, their sequence numbers, timestamps, reception reports and source descriptions can be attached to the wrong history. Audio from one origin can look like a discontinuity in another. A jitter buffer can be asked to reconcile clocks that were never related.

The original RTP standard, RFC 1889, made the identifier 32 bits and independent of the source's network address. That separation mattered in multicast conferences and through translators or mixers: an address could not serve as the universal name of a media source. Each source instead chose a random SSRC intended to be unique inside the particular RTP session.

Random choice removed a central allocation transaction from the path of a live conference. It did not remove coincidence. The protocol therefore treated collision recovery as part of ordinary conformance, not as an impossible edge case.

Low probability was not permission to omit recovery

RFC 3550 retained the design and made the probability boundary explicit. If 1,000 sources all start together and independently choose from 32 bits, its approximation puts the chance of at least one collision around 10^-4. One new source joining 1,000 already unique sources faces roughly 2×10^-7. Those are examples from the allocation model, not measurements of deployed calls.

The document also explains why implementation details can destroy the model. A local IP address is not sufficiently unique across private networks, translators or several sources on one host. An unseeded call to random() can make simultaneously started processes repeat the same sequence. A new participant can listen before transmitting, inspect the SSRCs already present and choose again before its first packet if necessary.

The historical choice is easy to miss: RTP did not promise that a number would never collide. It promised that participants would notice and recover when probability failed.

The old label left before the media did

The source-side rule is short. When a source discovers another source using its own SSRC, it sends an RTCP BYE packet for the old identifier and selects another random value. The replacement is first looked up in the local source table; if already occupied, another candidate must be generated.

BYE here does not necessarily mean that the camera, microphone or application has left. It retires one synchronization label. RFC 7656 later stated the consequence directly: an RTP stream has one SSRC at any moment, but its SSRC can change over time, and collision is one valid reason.

That distinction protects continuity. A consumer that equates SSRC with a person may show a false departure and a false arrival. An archive that keys permanently on the number may split one stream into two records. A policy engine that treats BYE as account revocation may apply an irreversible action to a routine namespace repair.

A receiver could preserve packets without awarding ownership

The case is different when a receiver sees two other sources colliding. RFC 3550 permits it to keep packets from one and discard packets from the other when different transport addresses or RTCP CNAMEs make the conflict visible. The colliding sources themselves are expected to move apart.

The first packet seen can therefore gain temporary operational preference. That is a receiver policy, not a judgment that the first sender owns the SSRC. If the established source later moves to a replacement identifier and its BYE clears the old entry, the previously suppressed source may become visible. If no BYE arrives, timeout eventually changes the receiver's evidence.

The source table must retain more than a number. RTP and RTCP can use different UDP source ports, so RFC 3550 records the first data and control transport addresses separately. A control chunk carrying a different CNAME can reveal a collision that a translator's common source address would otherwise conceal.

Collision detection doubled as a loop alarm

The same observation—one SSRC arriving from a different address—also appears when packets return through a forwarding loop. RTP cannot decide from the number and address alone whether it has found another source or a reflected copy of an existing one.

The algorithm therefore keeps a timed list of conflicting data and control addresses. When the conflict involves the participant's own SSRC, it changes the number once and records the address. If packets with the old conflict keep returning from that address, it ignores them instead of sending another BYE and choosing yet another number. Without that memory, one loop could produce an endless renaming and control-packet flood.

Mixers and translators are required to break loops they can create. Yet topology can erase the necessary evidence. RFC 7667 explains that loop detection depends on correctly preserved SSRC and CSRC identities; back-to-back independent sessions and some switching or selective-forwarding arrangements break the common namespace and move responsibility to another layer.

A changed address was evidence, not a verdict

RFC 3550 relaxed the original rule that a source must always change SSRC when its transport address changes. Some mobile applications legitimately keep a stream while the address moves. Receivers may accept the new address, but should resist flip-flopping if a genuine collision exists. A translator restart that changes its UDP port can make every forwarded source look looped until receiver state expires.

NAT adds a concrete version of the ambiguity. RFC 5135 notes that a changed source IP address or port paired with the same SSRC triggers collision processing. A short mapping lifetime can therefore complicate diagnostic tools and jitter buffers even though no second media origin deliberately selected the value.

An alert that says “SSRC collision” is thus a starting classification, not a security conclusion. Address history, RTCP identity, topology and timing decide which explanation remains plausible.

CNAME carried continuity that SSRC deliberately surrendered

RTCP CNAME occupies a different layer. RFC 7022 describes an endpoint whose SSRC may change after collision or application restart while its CNAME remains stable enough to associate related streams. The application can choose longer persistence for monitoring or a per-session value to reduce linkage across sessions.

CNAME is not the hidden true owner of an SSRC. Participants choose it, and the RFC warns that a participant can impersonate another chosen CNAME. It helps correlate streams and distinguish conflicting reports; it does not authenticate a person, institution or right to speak.

Modern signaling also does not make runtime recovery obsolete. RFC 8834 requires WebRTC endpoints to support random SSRC allocation and RFC 3550 collision resolution even where SSRCs can be announced in signaling. Both endpoints may begin using a new value before either has acknowledged the other's announcement, and auxiliary functions such as retransmission can introduce additional identifiers.

Sources and limits

The original rule is in RFC 1889; the mature probability, address-table, BYE, renaming and loop algorithm is in RFC 3550. NAT behavior is bounded by RFC 5135, CNAME continuity by RFC 7022, stream terminology by RFC 7656, topology by RFC 7667 and WebRTC use by RFC 8834. These documents define mechanisms and requirements. They do not measure current collisions, prove product conformance, identify a real caller or guarantee successful playout after a rename.