RTP и RTCP: протоколы для IP-телефонии

5. Трансляторы и микшеры

В дополнение к оконечным системам, RTP поддерживает такие понятия, как «трансляторы» и «микшеры», которые могут рассматриваться, как промежуточные системы уровня RTP.

5.1. Общее описание транслятора и микшера

Транслятор/микшер RTP соединяет два или более сегментов сети (сайтов) на транспортном уровне. Обычно, при этом каждый сайт определяется единым протоколом сетевого и транспортного уровня (например, UDP), групповым адресом или парой индивидуальных адресов и портом назначения транспортного уровня (трансляторы протоколов сетевого уровня, типа IP версии 4 в IP версии 6, могут присутствовать в сегменте сети незаметно для RTP). Одна система может служить в качестве транслятора или микшера для различных сеансов RTP, но при этом транслятор и микшер рассматриваются, как логически отдельные сущности.

Чтобы избежать зацикливания при использовании транслятора или микшера, должны соблюдаться следующие правила:

• каждый из сегментов, соединенных транслятором и микшером, участвующий в одном сеансе RTP, должен отличаться от всех других по крайней мере одним из параметров (протокол, адрес, порт) или должен быть изолирован от других сегментов на сетевом уровне;
• производная от первого правила — не должно быть множества трансляторов или микшеров, соединенных параллельно, если в соответствии с некоторой структурой они не разделяют между собой множество источников.

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

Может иметься большое многообразие трансляторов и микшеров, разработанных для различных целей и приложений. Некоторые типы данных систем должны шифровать/дешифровать данные, изменять тип кодирования данных или нижележащие протоколы или передавать данные между групповым адресом и одним или более индивидуальных адресов. Принципиальное различие между трансляторами и микшерами состоит в том, что транслятор передает потоки данных от различных источников отдельно, в то время как микшер объединяет их, формируя один новый поток.

Транслятор передает пакеты RTP с неизмененными идентификаторами SSRC. Это дает получателям возможность распознавать отдельные источники, даже если пакеты от всех источников прошли через один и тот же транслятор и содержат в качестве источника сетевой адрес транслятора. Некоторые виды трансляторов передают данные без изменений, а другие могут изменять тип кодирования данных и, таким образом, тип трафика RTP, а также временную метку. Если множество информационных пакетов преобразуется в один или, наоборот, один — во множество, то транслятор должен назначить исходящим пакетам новые порядковые номера. Потери во входящем потоке пакетов могут вызывать появление соответствующих промежутков в исходящих порядковых номерах. Получатели не смогут обнаружить присутствие транслятора, если каким-либо другим образом, не узнают какой тип трафика или транспортный адрес используется первоисточником данных.

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

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

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

5.2. Передача пакетов протокола RTCP трансляторами

В дополнение к передаче информационных пакетов (возможно, при модификации), трансляторы и микшеры должны также обрабатывать пакеты RTCP. Во многих случаях, они демонтируют составные пакеты RTCP, полученные от оконечных систем, объединяют информацию SDES и модифицируют пакеты SR или RR.

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

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

Блоки отчетов приема пакетов SR/RR. Транслятор передает отчеты приема, полученные от одного сегмента. Заметим, что этот поток имеет направление, противоположное направлению передачи данных. SSRC остается неизменным. Если транслятор объединяет отдельные информационные пакеты в один выходной пакет и, следовательно, изменяет порядковые номера, то он должен делать соответствующее преобразование для поля потерь пакетов и поля расширенного последнего порядкового номера. Это может быть сложным. В крайнем случае, может вообще не быть никакого действенного способа транслировать отчеты приема. Тогда транслятор может не передавать никаких отчетов о приеме вообще или синтезировать свой отчет, основанный на собственном приеме. Общее правило — нужно делать то, что имеет смысл в конкретной ситуации.

SDES. Трансляторы обычно передают без изменения информацию SDES от одного сегмента другим, но могут, например, если полоса пропускания ограничена, фильтровать информацию SDES не-CNAME. Канонические имена CNAME должны передаваться для обнаружения коллизий идентификатора SSRC. Транслятор, который генерирует свои собственные пакеты RR, должен посылать информацию SDES CNAME о себе тем же сегментам, которым он посылает пакеты RR.

BYE. Трансляторы передают пакеты BYE неизмененными. Если трансляторы собираются прекращать передачу пакетов, то они должны генерировать пакеты BYE со своими собственными идентификаторами SSRC.

APP. Трансляторы передают пакеты APP без изменения.

5.3. Передача пакетов протокола RTCP микшерами

Поскольку микшер генерирует новый собственный поток данных, он не транслирует пакеты SR или RR, а вместо этого генерирует новую информацию для обеих сторон.

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

Блоки отчетов о приеме пакетов SR/RR. Микшер генерирует свои собственные отчеты приема для источников в каждом сегменте и посылает их наружу только в те же самые сегменты. Он не посылает этих отчетов приема другим сегментам и не передает отчеты о приеме из одного сегмента в другие, потому что эти источники не являются источниками синхронизации SSRC (являются только включаемыми источниками CSRC).

SDES. Микшеры обычно передают без изменения информацию SDES от одного сегмента другим, но могут, например, если полоса пропускания ограничена, фильтровать информацию SDES не-CNAME. Канонические имена CNAME должны передаваться, чтобы обеспечить обнаружение коллизий идентификатором SSRC (идентификатор в списке CSRC, сгенерированном микшером, может конфликтовать с идентификатором SSRC, сгенерированным оконечной системой). Микшер должен послать информацию SDES CNAME о себе тем сегментам, которым он посылает пакеты SR или RR.

Так как микшеры не передают пакеты SR или RR, то они обычно извлекают пакеты SDES из составного пакета RTCP. Чтобы минимизировать избыточность, части пакетов SDES могут объединяться в один пакет SDES, который затем помещается в пакет SR или RR, генерируемый микшером. Интенсивность генерации пакетов RTCP на разных сторонах микшера может быть различной.

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

BYE. Микшеры должны передавать пакеты BYE. Если микшеры собираются прекратить пересылку пакетов, то они должны генерировать пакеты BYE с их собственными идентификаторами SSRC.

APP. Передача микшерами пакетов APP определяется приложением.

Сеанс RTP может включать систему микшеров и трансляторов. Если два микшера включены каскадно, то пакеты, полученные микшером, возможно, уже были смешаны и могут включать список CSRC со множеством идентификаторов. Второй микшер при этом должен формировать список включаемых источников CSRC для исходящего пакета, используя идентификаторы CSRC из уже смешанных входных пакетов и идентификаторы источников синхронизации SSRC из несмешанных входных пакетов. Как и в случае некаскадных микшеров, если результирующий список CSRC имеет больше, чем 15 идентификаторов, то остальные идентификаторы не могут быть в него включены.

6. Зацикливания и коллизии, связанные с неуникальностью идентификатора SSRC

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

Использовать в качестве идентификатора локальный сетевой адрес (такой, как адрес IPv4) не следует. Такой адрес может не быть уникальным, так как трансляторы и микшеры RTP позволяют взаимодействать множеству сетей с различными адресными пространствами. Множество источников данных, выполняющихся на одном и том же хосте, также могут конфликтовать. Не следует получать идентификатор SSRC, просто вызывая функцию random(), без инициализации состояния.

6.1. Вероятность коллизии

Идентификаторы выбираются случайно, поэтому возможно, что два или более источников выберут для него одно и то же значение. Коллизия с наибольшей вероятностью произойдет, если все источники начнут работу одновременно, — например, когда это вызвано автоматически некоторым событием управления сеанса связи. Если N — число источников, а L — длина идентификатора (здесь 32 бита), то вероятность того, что два источника независимо выберут одну и ту же величину, может быть приблизительно рассчитана для больших N по формуле:

1-exp(-N**2/2**(L+1)).

Для N=1000, эта вероятность приблизительно равна 10^-4.

Обычно вероятность коллизий — намного ниже, чем вероятность худшего случая, представленная выше. Когда один новый источник вступает в сеанс связи RTP, в котором все другие источники уже имеют уникальные идентификаторы, вероятность коллизии равна N/2^L. Для N=1000, она приблизительно равна 2*10^-7.

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

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

Хотя вероятность коллизии идентификаторов 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 или если в течение длительного интервала времени никакие пакеты не поступали (см. раздел 4.2.1).

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

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

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

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

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

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

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

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

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

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

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

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

7.2. Аутентификация и обеспечение целостности сообщения

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