Schulzrinne, et al Standards Track [Page 12]
RFC 1889 RTP January 1996
inserted by mixers, using the SSRC identifiers of contributing
sources. For example, for audio packets the SSRC identifiers of
all sources that were mixed together to create a packet are
listed, allowing correct talker indication at the receiver.
5.2 Multiplexing RTP Sessions
For efficient protocol processing, the number of multiplexing points
should be minimized, as described in the integrated layer processing
design principle [1]. In RTP, multiplexing is provided by the
destination transport address (network address and port number) which
define an RTP session. For example, in a teleconference composed of
audio and video media encoded separately, each medium should be
carried in a separate RTP session with its own destination transport
address. It is not intended that the audio and video be carried in a
single RTP session and demultiplexed based on the payload type or
SSRC fields. Interleaving packets with different payload types but
using the same SSRC would introduce several problems:
1. If one payload type were switched during a session, there
would be no general means to identify which of the old
values the new one replaced.
2. An SSRC is defined to identify a single timing and sequence
number space. Interleaving multiple payload types would
require different timing spaces if the media clock rates
differ and would require different sequence number spaces
to tell which payload type suffered packet loss.
3. The RTCP sender and receiver reports (see Section 6.3) can
only describe one timing and sequence number space per SSRC
and do not carry a payload type field.
4. An RTP mixer would not be able to combine interleaved
streams of incompatible media into one stream.
5. Carrying multiple media in one RTP session precludes: the
use of different network paths or network resource
allocations if appropriate; reception of a subset of the
media if desired, for example just audio if video would
exceed the available bandwidth; and receiver
implementations that use separate processes for the
different media, whereas using separate RTP sessions
permits either single- or multiple-process implementations.
Using a different SSRC for each medium but sending them in the same
RTP session would avoid the first three problems but not the last
two.
