CSRC and SSRC in RTP

Regarding your question "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??"

It is not specifically true because when there are many sources the video/audio is mixed by RTP mixer and the SSRC in this case is the RTP mixer SSRC which is not the source of the RTP packet sender, in order to know the sources you need to look at the CSRC array which has these sources identified by unique SSRC the size of the array is given also by the header field CC: count CSRC.

If the audio/video is not combined (uni-cast) then the SSRC is of the sender of this video/audio and CSRC not filled.

Helpful presentation: http://voip.netlab.uky.edu/~fei/teaching/cs671/slides/rtp.pdf

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.