rtpsession: Collision handling leads to dead-end for receivers
My current use case is that I would like to test multicast streaming, with RTCP enabled on a single host. So all my source/sink have the "loop" property set to it's default, TRUE. In this mode, all RTCP report are sent back to the group, so that all participants can see these reports. The side effect is that the client will receive it's own report.
By receiving it's own report, a collision is detected. At this stage, there is no indication if it's a collision or a loop in the network. As per specification, the address from which the colliding packet is originating is saved. Internally we bye the internal source and create a new one.
The goal is that when we find another collision with the new SSRC, we detect the loop by finding back the same address and start ignoring it. But in practice we never reach this because in the case of a single stream receiver, the RTPSource that has been schedule to Bye was the last one. In this case, we send EOS on the rtpsession pad, which renders all pads in the chain unusable. So all reports we try to send silently failed with FLOW_EOS (which we kindly ignore).
This state is unrecoverable, since we don't own these pads. The only way would be to destroy the session and create a new one, but then we'll get another collision and another EOS will be sent. I have tried so far delaying the EOS event, but it seems to break a unit test:
https://gitlab.collabora.com/rist/gst-plugins-good/commit/4e7665f184a7a8fd5e75d57a726f11dd24a9559c