Разрешение коллизий и обнаружение зацикливаний

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

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

Транслятор может ошибочно передавать пакет той же многопользовательской группе, от которой он получил пакет, или непосредственно, или через цепь трансляторов. В этом случае один и тот же пакет появляется несколько раз, возникая из различных источников сети.

Два транслятора, неправильно установленные параллельно (с одними и теми же многопользовательскими группами с обеих сторон), передают пакеты от одной многопользовательской группы другой. Однонаправленные трансляторы производят две копии; двунаправленные трансляторы создают зацикливание.

Микшер может замыкать петлю зацикливания, посылая пакеты тому же самому транспортному адресу, от которого он их получает, или непосредственно, или через другой микшер (транслятор). В этом случае источник может идентифицироваться и как SSRC в пакете данных, и как CSRC в смешанном пакете данных.

Источник может обнаружить, что зациклены его собственные пакеты, или пакеты из другого источника (зацикливание третьей стороны).

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

Чтобы обнаружить и разрешить эти конфликты, реализация RTP должна включать специальный алгоритм. Такой алгоритм состоит в разрешении коллизии на основе использования собственного идентификатора SSRC участника, посылке пакета BYE протокола RTCP для старого идентификатора и выборе нового. Алгоритм может использоваться, когда транспортный адрес источника является общим для пакетов RTP и RTCP этого источника. Для поддержки приложений, которые не удовлетворяют этому ограничению, алгоритм нужно изменить.

Алгоритм требует ведения таблицы соответствия идентификатора источника и транспортного адреса источника, от которого идентификатор был (вначале) получен. Каждый идентификатор SSRC или CSRC, полученный в информационном или управляющем пакете, разыскивается в этой таблице для обработки содержащихся в пакете данных или управляющей информации. Для управляющих пакетов каждый элемент с собственным идентификатором SSRC (например, часть пакета SDES) требует отдельного поиска (исключением является SSRC в блоке отчета приема). Если SSRC или CSRC не найден, то создается новая запись таблицы. Записи таблицы уничтожаются, если поступает пакет BYE протокола RTCP с соответствующим SSRC или если в течение длительного интервала времени никакие пакеты не поступали.

Чтобы отследить зацикливания собственных информационных пакетов участника, также необходимо хранить отдельный список транспортных адресов (не идентификаторов) конфликтующих источников. Заметим, что этот список должен быть коротким. Обычно он является пустым. Каждый элемент в этом списке содержит транспортный адрес источника и время получения последнего конфликтующего пакета. Элемент может удаляться из списка, когда из данного источника в течение порядка десяти интервалов отчетности RTCP не поступило никаких конфликтующих пакетов.

Когда из-за коллизии выбирается новый идентификатор SSRC, то его предполагаемое значение сначала разыскивается в исходной таблице идентификаторов, чтобы видеть, не находится ли оно уже в использовании некоторым другим источником. Если это так, то генерируется другое значение, и процесс повторяется.

Зацикливание пакетов данных с групповым адресом может вызывать лавинообразный рост числа пакетов в сети. Требуется, чтобы все микшеры и трансляторы выполняли обнаружение и разрушение зацикливаний. Это должно ограничить излишний рост трафика не более, чем одной двойной копией, пока причина зацикливания не будет найдена. В чрезвычайных ситуациях, когда микшер или транслятор не разрушает зацикливание, что приводит к значительному росту трафика, для оконечных систем может быть необходимо полное прекращение передачи информационных или управляющих пакетов. Это решение может зависеть от приложения. Состояние ошибки при этом должно быть соответствующим образом обозначено. Вновь передача может быть предпринята после длительного (со случайным значением длительности) интервала времени (порядка нескольких минут).

Безопасность

Услуги обеспечения безопасности связи, которые требуются приложениям RTP, включая аутентификацию, целостность и конфиденциальность, могут обеспечиваться протоколами нижележащих уровней. Так как RTP может использоваться с различными протоколами нижележащих уровней, в том числе и не предоставляющими подобного рода услуг, а потребность в конфиденциальности связи присутствует в звуковых и видеоприложениях, то в протоколе RTP предусмотрена услуга обеспечения конфиденциальности, когда услуги нижележащего уровня недоступны. Избыточность протокола для обеспечения этой услуги низка, так что плата за нее является минимальной. В будущем это обслуживание может быть заменено услугами нижележащего уровня.

Конфиденциальность

Обеспечение конфиденциальности означает, что декодировать данные из полученного пакета может только адресат; для других пакет не содержит никакой полезной информации. Конфиденциальность обеспечивается шифрованием.

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

Для протокола RTCP позволено декомпозировать составной пакет RTCP на два пакета нижележащего уровня, один из которых шифруется, а другой передается в открытом виде. Например, информация SDES может шифроваться, в то время как отчеты о приеме - передаваться в открытом виде для обеспечения мониторинга третьей стороной, которая не владеет ключом шифрования.

Присутствие шифрования и использование корректного ключа подтверждается получателем через заголовок или результаты проверки корректности передаваемых данных.

Заданный по умолчанию алгоритм шифрования — это стандарт шифрования данных DES (Data Encryption Standard) в режиме цепочки шифруемых блоков (CBC — cipher block chaining). Вектор инициализации является нулевым, потому что случайное начало блока данных обеспечивается заголовком пакета RTP или произвольным префиксом для составных пакетов RTCP. Реализации, которые поддерживают шифрование, должны всегда по умолчанию поддерживать алгоритм DES в режиме CBC, чтобы максимизировать способность к взаимодействию. Этот метод выбран в качестве задаваемого по умолчанию, потому что он является простым и практичным при использовании в экспериментальных аудио- и видеосистемах при работе в сети Internet. Другие алгоритмы шифрования могут определяться динамически средствами не-RTP для конкретного сеанса связи.

Как альтернатива шифрованию на уровне RTP профили могут определять дополнительные типы трафика для шифрованных данных. Этот метод позволяет шифровать только передаваемые данные, а заголовки оставлять открытыми для приложений там, где это желательно. Это может быть особенно полезно для аппаратных средств, выполняющих как дешифрование, так и декодирование.