CSRC и SSRC в RTP

Я очень новичок в RTP, может кто-нибудь объяснить о CSRC и SSRC вообще?

Из http://www.rfc-editor.org/rfc/rfc3550.txt, что он говорит: Поле SSRC идентифицирует источник синхронизации. Означает ли это, что в сети может быть много отправителей, которые вносят свой вклад в RTP (сеть многоадресной рассылки) и идентифицируют, из какого источника идет пакет?

CSRC: Contributing source (CSRC): источник потока пакетов RTP, который внес вклад в объединенный поток, создаваемый RTP-микшером (см. ниже). Не понял.

Может ли кто-нибудь объяснить пример, пожалуйста? Благодаря

Ответ 1

взято из ссылка:

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

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

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

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

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

Ответ 2

Относительно вашего вопроса "Значит ли это, что в сети может быть много отправителей, которые вносят свой вклад в RTP (сеть многоадресной рассылки) и идентифицируют, из какого источника идет пакет?"

Это не совсем верно, потому что, когда есть много источников, видео/аудио смешивается с помощью RTP-микшера, а SSRC в этом случае является RSR-микшером SSRC, который не является источником отправителя пакета RTP, чтобы знать источников вам нужно посмотреть на массив CSRC, который идентифицирует эти источники уникальным SSRC, размер массива задается также полем заголовка CC: count CSRC.

Если аудио/видео не объединено (un-cast), то SSRC отправителя этого видео/аудио и CSRC не заполняется.

Полезная презентация: http://voip.netlab.uky.edu/~fei/teaching/cs671/slides/rtp.pdf

Ответ 3

  • SSRC:

Идентификатор источника синхронизации (32 бита) четко отличает источник потока данных. Источники синхронизации в одном сеансе RTP будут уникальными.

2.CSRC:

Идентификаторы исходных ресурсов (по 32 бита) суммируют источники-источники для потока, который был создан из нескольких источников.

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol