The RTP SSRC is meant to LABEL streams from different sources, that is, each sender in a conference has its own SSRC. It has been suggested to have a single source, using the same RTP session (identified by source and destination addresses and ports), send different media, such as an audio and video stream, using different SSRCs.

This is generally a bad idea for the following reasons:

An RTP mixer normally combines all the SSRCs it receives on an RTP session according to the composition method that is appropriate for that session (e.g., mixing for audio). If multiple media are sent on one session, then the SSRCs must be segregated per medium based on external information. That gets complicated with sources coming from multiple places. It is similarly more complicated for and end node receiver to handle streams coming from multiple sources to the same RTP session if some of those sources don't all get fed to the same compositor (mixer, selector, whatever).

Carrying multiple media in one RTP session precludes the use of different network PATHS or network resource allocations if appropriate. For the typical synchronized audio/video stream one may not want different paths, but it is not hard to imagine situations where one medium should go VIA a low-bandwidth, low-delay terrestrial path while another can tolerate the LONGER delay of a satellite path in order to get higher bandwidth.

Carrying multiple media in one RTP session precludes reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth. This is not an issue for UNICAST since that choice of media would be controlled by the exchange with the sender, but it is valuable for multicast with heterogeneous receivers.

Carrying multiple media in one RTP session precludes receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Consider the development of "desk area networks" at MIT, ISI and other places in which the display and the speaker may have different IP addresses. This is an instance of the general philosophy of demultiplexing at the lowest level possible.

Also, making the SSRC fixed is a problem in the multicast case because collision resolution might require changing the SSRC id.(contributed by Steve Casner)

The RTP SSRC is meant to label streams from different sources, that is, each sender in a conference has its own SSRC. It has been suggested to have a single source, using the same RTP session (identified by source and destination addresses and ports), send different media, such as an audio and video stream, using different SSRCs.

This is generally a bad idea for the following reasons:

An RTP mixer normally combines all the SSRCs it receives on an RTP session according to the composition method that is appropriate for that session (e.g., mixing for audio). If multiple media are sent on one session, then the SSRCs must be segregated per medium based on external information. That gets complicated with sources coming from multiple places. It is similarly more complicated for and end node receiver to handle streams coming from multiple sources to the same RTP session if some of those sources don't all get fed to the same compositor (mixer, selector, whatever).

Carrying multiple media in one RTP session precludes the use of different network paths or network resource allocations if appropriate. For the typical synchronized audio/video stream one may not want different paths, but it is not hard to imagine situations where one medium should go via a low-bandwidth, low-delay terrestrial path while another can tolerate the longer delay of a satellite path in order to get higher bandwidth.

Carrying multiple media in one RTP session precludes reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth. This is not an issue for unicast since that choice of media would be controlled by the exchange with the sender, but it is valuable for multicast with heterogeneous receivers.

Carrying multiple media in one RTP session precludes receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. Consider the development of "desk area networks" at MIT, ISI and other places in which the display and the speaker may have different IP addresses. This is an instance of the general philosophy of demultiplexing at the lowest level possible.

Also, making the SSRC fixed is a problem in the multicast case because collision resolution might require changing the SSRC id.(contributed by Steve Casner)