Schulzrinne, et al Standards Track [Page 45]
RFC 1889 RTP January 1996
translators would produce two copies; bidirectional translators
would form a loop.
o A mixer can close a loop by sending to the same transport
destination upon which it receives packets, either directly or
through another mixer or translator. In this case a source
might show up both as an SSRC on a data packet and a CSRC in a
mixed data packet.
A source may discover that its own packets are being looped, or that
packets from another source are being looped (a third-party loop).
Both loops and collisions in the random selection of a source
identifier result in packets arriving with the same SSRC identifier
but a different source transport address, which may be that of the
end system originating the packet or an intermediate system.
Consequently, if a source changes its source transport address, it
must also choose a new SSRC identifier to avoid being interpreted as
a looped source. Loops or collisions occurring on the far side of a
translator or mixer cannot be detected using the source transport
address if all copies of the packets go through the translator or
mixer, however collisions may still be detected when chunks from two
RTCP SDES packets contain the same SSRC identifier but different
CNAMEs.
To detect and resolve these conflicts, an RTP implementation must
include an algorithm similar to the one described below. It ignores
packets from a new source or loop that collide with an established
source. It resolves collisions with the participant's own SSRC
identifier by sending an RTCP BYE for the old identifier and choosing
a new one. However, when the collision was induced by a loop of the
participant's own packets, the algorithm will choose a new identifier
only once and thereafter ignore packets from the looping source
transport address. This is required to avoid a flood of BYE packets.
This algorithm depends upon the source transport address being the
same for both RTP and RTCP packets from a source. The algorithm would
require modifications to support applications that don't meet this
constraint.
This algorithm requires keeping a table indexed by source identifiers
and containing the source transport address from which the identifier
was (first) received, along with other state for that source. Each
SSRC or CSRC identifier received in a data or control packet is
looked up in this table in order to process that data or control
information. For control packets, each element with its own SSRC,
for example an SDES chunk, requires a separate lookup. (The SSRC in a
reception report block is an exception.) If the SSRC or CSRC is not
Schulzrinne, et al Standards Track [Page 46]
RFC 1889 RTP January 1996
found, a new entry is created. These table entries are removed when
an RTCP BYE packet is received with the corresponding SSRC, or after
no packets have arrived for a relatively long time (see Section
6.2.1).
