RTP: обнаружение коллизий SSRC в одноадресных сеансах
Из RFC 3550:
Если получатель обнаруживает, что два других источника сталкиваются, он МОЖЕТ удерживать пакеты от одного и отбрасывать пакеты от другого, когда это может быть обнаружено различными транспортными адресами источника или CNAME. Ожидается, что два источника разрешат столкновение, чтобы ситуация не длилась долго.
Как в одноадресной конфигурации с одним получателем и двумя отправителями, которые общаются только с получателем, как коллизии SSRC могут быть обнаружены отправителями?
Можно предположить, что получатель должен периодически отправлять все известные CNAME всем известным участникам (отправителям). Это правда? Но как в этом случае отправители будут связывать полученный CNAME с транспортным адресом?
Обновить:
Как показано ниже, существует два отдельных сеанса RTP с отдельными пространствами SSRC, поэтому обнаружение коллизий не требуется.
Отличительной особенностью сеанса RTP является то, что каждый поддерживает полное отдельное пространство идентификаторов SSRC
А также:
Набор участников, включенных в один сеанс RTP, состоит из тех, кто может получить идентификатор SSRC, передаваемый любым из участников либо в RTP в качестве SSRC, либо в CSRC (также определенном ниже) или в RTCP.
И есть даже пример для ситуации, которую я описал:
Например, рассмотрим трехстороннюю конференцию, реализованную с использованием одноадресного UDP, причем каждый участник получает от двух других по отдельным парам портов. Если каждый участник отправляет отзыв RTCP о данных, полученных от одного другого участника, только этому участнику, то конференция состоит из трех отдельных сеансов RTP "точка-точка".
2 ответа
Насколько я понимаю, это правило применимо только для многоадресной рассылки и / или зацикливания пакетов. При описанной вами настройке (два отправителя осуществляют одноадресную передачу одному получателю), они не знают друг друга и не предпринимают никаких мер для обнаружения столкновения. Это задача получателя для решения этой проблемы. Если получатель является медиапроцессором, он, вероятно, будет выступать в качестве конечной стороны, переформатировать поток и повторно отправлять необходимое содержимое в рамках своего собственного SSRC.
Прощание может быть отправлено с Причиной, установленной на соответствующее значение.
См. http://www.ietf.org/rfc/rfc3550.txt @ 6.6. BYE: Прощай, пакет RTCP
По традиции я видел значение "ssrc", используемое для обозначения изменения SSRC.
Кроме того, если пакет RTCP получен с новым SSRC, ssrc пакетов RTP, вероятно, также должен измениться и, следовательно, будет обработан при проверке порядкового номера, если ssrc изменен, но порядковый номер все еще действителен, тогда будет использоваться новый ssrc.,