CSRC and SSRC in RTP

Question

I am very new to RTP , can some one explain about the CSRC and SSRC in general?

From http://www.rfc-editor.org/rfc/rfc3550.txt , what it says is : The SSRC field identifies the synchronization source. Does it mean , in network there may be many senders who are contributing to RTP (multicast network) and to identify from which source the packet is coming??

CSRC : Contributing source (CSRC): A source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer (see below). Did not understand.

can some one explain with example please? Thanks

Answer 1

taken from link:

SSRC Identifies the synchronization source. The value is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC. Although the probability of multiple sources choosing the same identifier is low, all RTP implementations must be prepared to detect and resolve collisions. If a source changes its source transport address, it must also choose a new SSRC to avoid being interpreted as a looped source.

CSRC An array of 0 to 15 CSRC elements identifying the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 may be identified. CSRC identifiers are 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.

To be honest, I have never seen anyone actually use SSRC or CSRC in any meaningful way. In all the code I've dealt with, we just generate a random number in SSRC and don't never bother filling in CSRC.

I would guess SSRC may be useful in tracing and/or detecting looping audio paths.

I would guess CSRC may be useful for a sip endpoint receiving audio from a conference servers where multiple audio sources are mixed together as hinted in the quote above. As I said tho, in the conference server code I've dealt with, we don't bother.