Identificateur de source dupliqué dans les flux RTP. Peut gâcher les rapports RTCP?

Question

Tout d'abord, cela ressemble à RTP: SSRC collision detection in unicast sessions, mais la question est d'une autre portée.

Le scénario:

j'ai un groupe d'agents de médias de communication avec une passerelle média central.

Un arrangement comme

{} DeviceA < --RTP -> {Media Gateway} < --RTP -> {} DeviceB

pour une seule session

et

{Device1, Device2 ... DeviceN} < --RTP -> {Media Gateway} < --RTP -> {Device11, Device22 ... Devic eNN}

Dans une forme générale, avec DeviceN dans une session RTP avec DeviceNN. Fondamentalement, ils sont en train d'améliorer les RTP sans aucun problème (prouvé par l'analyse de Wireshark), mais, sur l'outil de reporting RTCP que nous avons, il est possible de voir qu'il y a des sessions avec le même SSRC (probablement un bug des périphériques, qui ne génèrent pas l'ID de manière aléatoire).

Ma question: Voyez-vous un scénario où, ayant des sessions RTP, avec le même identifiant SSRC, nous commençons à voir RTCP avec des informations incompatibles étant émises? Encore une fois, toutes les sessions RTP sont bonnes, si nous regardons Wireshark (pas de perte de paquets ou de gigue significative), mais les RTCP présentent des niveaux extrêmement élevés de mauvais réseau. Je pense que: si la passerelle média rencontre une collision, elle devrait stopper les flux RTP pour un SSRC donné, en laissant SEULEMENT un en vie, alors, le flux RTCP pour ce flux devrait également être bon. Ai-je raison?

Appréciez vos commentaires!

Answer 1

Le problème dans mon système s'est produit en raison d'un problème avec les points finaux produisant des paquets de bruit de confort, ce qui n'était pas bon pour les passerelles média. Le bruit de confort doit être configuré à l'avance sur la passerelle média, cela n'a pas été fait. Obtenir ride de ces paquets de bruit de confort est également une solution. Donc, le conseil est: tracez les MG et les points de terminaison, toujours.