CSRC и SSRC в RTP

принято от ссылки:

SSRC определяет источник синхронизации. Значение выбирается случайным образом, с целью, чтобы не было двух источников синхронизации внутри тот же сеанс RTP будет иметь тот же SSRC. Хотя вероятность из нескольких источников выбор одного и того же идентификатора низкий, все RTP реализации должны быть готовы к обнаружению и разрешению коллизий. Если источник изменяет свой адрес транспорта источника, он также должен выбрать новый SSRC, чтобы избежать интерпретации как зацикленного источника.

CSRC массив от 0 до 15 элементов CSRC, идентифицирующих источники для полезной нагрузки, содержащейся в этом пакете. Этот количество идентификаторов задается полем CC. Если есть более 15 источники взносов, могут быть определены только 15. СРО идентификаторы вставляются микшерами, используя идентификаторы SSRC вклада источники. Например, для аудиопакетов SSRC идентификаторы всех перечислены источники, которые были смешаны вместе для создания пакета, позволяющ правильной индикации Говоруна на приемнике.

честно говоря, я никогда не видел, чтобы кто-то действительно использовал SSRC или CSRC каким-либо значимым образом. Во всем коде, с которым я имел дело, мы просто генерируем случайное число в SSRC и никогда не утруждаем себя заполнением CSRC.

Я бы предположил, что SSRC может быть полезен при трассировке и / или обнаружении циклических звуковых путей.

Я бы предположим, CSRC может быть полезен для конечной точки sip, получающей аудио с серверов конференций, где несколько источников звука смешиваются вместе, как указано в цитате выше. Как я уже сказал, в коде конференц-сервера, с которым я имел дело, мы не беспокоимся.