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:

  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.


Next: 5.3 Profile-Specific Modifications to the RTP Header

Connected: An Internet Encyclopedia
5.2 Multiplexing RTP Sessions