Should the RTP SSRC be used for demultiplexing different streams for the same RTP session?
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