First of all, this is somenting like RTP: SSRC collision detection in unicast sessions, but the question is on other scope.
The scenario:
I have a bunch of media agents communicating with a central media gateway.
An arrangement like
{DeviceA} <--RTP--> {Media Gateway} <--RTP--> {DeviceB}
for a single session
and
{Device1, Device2 ... DeviceN} <--RTP--> {Media Gateway} <--RTP--> {Device11, Device22 ... DeviceNN}
In a general form, with DeviceN in a RTP session with DeviceNN.
Basically they are exhanging RTPs without any issues (proved by Wireshark analysis), but, on the RTCP reporting tool we have, it is possible to see that there are sessions with the same SSRC (probably a bug from the devices, which are not generating the ID randomly enough).
My question: Do you see any scenario where, having RTP sessions, with the the same SSRC ID, we start to see RTCP with mismatched info being emmited?
Again, all the RTP sessions are good, if we look at Wireshark (no packet loss or significant jitter), but RTCPs are presenting extremely high levels of bad networking.
I am thinking that: if the media gateway got a collision, it should stop the RTP streams for a given SSRC, leaving ONLY one alive, then, the RTCP stream for that stream should be good as well. Am I right on this?
Appreciate your comments!
The issue in my system happened due to a problem with endpoints producing comfort noise packets, which was something not good for the media gateways. The confort noise should be configured in advance on the media gateway, it was not done. Getting ride of these comfort noise packets is a solution as well. So, the advice is: trace the MGs and endpoints, always.