THEN (optionally) count occurrence of own traffic looped.
mark current time in conflicting address list entry.
ABORT processing of data packet or control element.
log occurrence of a collision.
create a new entry in the conflicting address list and
mark current time.
send an RTCP BYE packet with the old SSRC identifier.
choose a new identifier.
create a new entry in the source identifier table with the
old SSRC plus the source transport address from the packet
being processed.
CONTINUE with normal processing.
In this algorithm, packets from a newly conflicting source address
will be ignored and packets from the original source will be kept.
(If the original source was through a mixer and later the same source
is received directly, the receiver may be well advised to switch
unless other sources in the mix would be lost.) If no packets arrive
from the original source for an extended period, the table entry will
be timed out and the new source will be able to take over. This might
occur if the original source detects the collision and moves to a new
source identifier, but in the usual case an RTCP BYE packet will be
received from the original source to delete the state without having
to wait for a timeout.
When a new SSRC identifier is chosen due to a collision, the
candidate identifier should first be looked up in the source
identifier table to see if it was already in use by some other
source. If so, another candidate should be generated and the process
repeated.
A loop of data packets to a multicast destination can cause severe
network flooding. All mixers and translators are required to
implement a loop detection algorithm like the one here so that they
can break loops. This should limit the excess traffic to no more than
one duplicate copy of the original traffic, which may allow the
session to continue so that the cause of the loop can be found and
fixed. However, in extreme cases where a mixer or translator does not
properly break the loop and high traffic levels result, it may be
necessary for end systems to cease transmitting data or control
packets entirely. This decision may depend upon the application. An
error condition should be indicated as appropriate. Transmission
might be attempted again periodically after a long, random time (on
the order of minutes).
Schulzrinne, et al Standards Track [Page 48]
RFC 1889 RTP January 1996
9. Security
Lower layer protocols may eventually provide all the security
services that may be desired for applications of RTP, including
authentication, integrity, and confidentiality. These services have
recently been specified for IP. Since the need for a confidentiality
service is well established in the initial audio and video
applications that are expected to use RTP, a confidentiality service
is defined in the next section for use with RTP and RTCP until lower
layer services are available. The overhead on the protocol for this
service is low, so the penalty will be minimal if this service is
obsoleted by lower layer services in the future.
