Connected: An Internet Encyclopedia
5.2 Multiplexing RTP Sessions
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1889
Up:
5. RTP Data Transfer Protocol
Prev: 5.1 RTP Fixed Header Fields
Next: 5.3 Profile-Specific Modifications to the RTP Header
5.2 Multiplexing RTP Sessions
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:
- 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.
- 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.
- 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.
- An RTP mixer would not be able to combine interleaved
streams of incompatible media into one stream.
- 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.
Next: 5.3 Profile-Specific Modifications to the RTP Header
Connected: An Internet Encyclopedia
5.2 Multiplexing RTP Sessions