SDES: Mixers typically forward without change the SDES information
they receive from one cloud to the others, but may, for example,
decide to filter non-CNAME SDES information if bandwidth is
limited. The CNAMEs must be forwarded to allow SSRC identifier
collision detection to work. (An identifier in a CSRC list
generated by a mixer might collide with an SSRC identifier
generated by an end system.) A mixer must send SDES CNAME
information about itself to the same clouds that it sends SR or
RR packets.
Since mixers do not forward SR or RR packets, they will typically be
extracting SDES packets from a compound RTCP packet. To minimize
overhead, chunks from the SDES packets may be aggregated into a
single SDES packet which is then stacked on an SR or RR packet
originating from the mixer. The RTCP packet rate may be different on
each side of the mixer.
A mixer that does not insert CSRC identifiers may also refrain from
forwarding SDES CNAMEs. In this case, the SSRC identifier spaces in
the two clouds are independent. As mentioned earlier, this mode of
operation creates a danger that loops can't be detected.
Schulzrinne, et al Standards Track [Page 43]
RFC 1889 RTP January 1996
BYE: Mixers need to forward BYE packets. They should generate BYE
packets with their own SSRC identifiers if they are about to
cease forwarding packets.
APP: The treatment of APP packets by mixers is application-specific.
7.4 Cascaded Mixers
An RTP session may involve a collection of mixers and translators as
shown in Figure 3. If two mixers are cascaded, such as M2 and M3 in
the figure, packets received by a mixer may already have been mixed
and may include a CSRC list with multiple identifiers. The second
mixer should build the CSRC list for the outgoing packet using the
CSRC identifiers from already-mixed input packets and the SSRC
identifiers from unmixed input packets. This is shown in the output
arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case
of mixers that are not cascaded, if the resulting CSRC list has more
than 15 identifiers, the remainder cannot be included.
8. SSRC Identifier Allocation and Use
The SSRC identifier carried in the RTP header and in various fields
of RTCP packets is a random 32-bit number that is required to be
globally unique within an RTP session. It is crucial that the number
be chosen with care in order that participants on the same network or
starting at the same time are not likely to choose the same number.
It is not sufficient to use the local network address (such as an
IPv4 address) for the identifier because the address may not be
unique. Since RTP translators and mixers enable interoperation among
multiple networks with different address spaces, the allocation
patterns for addresses within two spaces might result in a much
higher rate of collision than would occur with random allocation.
Multiple sources running on one host would also conflict.
It is also not sufficient to obtain an SSRC identifier simply by
calling random() without carefully initializing the state. An example
of how to generate a random identifier is presented in Appendix A.6.
8.1 Probability of Collision
