RTP: SSRC collision detection in unicast sessions

Question

From RFC 3550:

If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other when this can be detected by different source transport addresses or CNAMEs. The two sources are expected to resolve the collision so that the situation doesn't last.

In a unicast configuration with one receiver and two senders that only communicate with receiver, how SSRC collisions may be detected by senders?

One guess is that receiver should periodically send all known CNAMEs to all known participants (senders). Is it true? But in this case, how senders will associate received CNAME with a transport address?

Update:

As answered below, there are two separate RTP sessions with separate SSRC spaces, so no collision detection is needed.

The distinguishing feature of an RTP session is that each maintains a full, separate space of SSRC identifiers

And:

The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP.

And there is even an example for the situation I have described:

For example, consider a three- party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions.

Answer 1

As far as I understand, this rule is applicable only for multicasting and/or loops of packets. With the setup described by you (two senders are unicasting to one receiver), they don't know each other and have no measures to detect the collision. It's receiver task to deal with this issue. If the receiver is media processor, it likely will act as an end party, reformat the stream and resend needed contents under its own SSRC.

Answer 2

A Goodbye can be sent with a Reason set to the appropriate value..

See http://www.ietf.org/rfc/rfc3550.txt @ 6.6 BYE: Goodbye RTCP Packet

By tradition I have seen the value "ssrc" used to indicate the SSRC is changing.

Additionally if a RTCP packet is received with a new SSRC the RTP packets ssrc should probably change as well and thus would be handled when verifying the sequence number, if the ssrc is changed but the sequence number is still valid then the new ssrc will be used.