Интегрированные сети ISDN

         

Формат пакета, задаваемого приложением



Рисунок 4.4.9.3.16. Формат пакета, задаваемого приложением


Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрация типа пакета. APP-пакеты с не узнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, после чего его следует зарегистрировать в IANA (Internet Assigned Numbers Authority), как новый тип RTCP-пакета.

Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов.

Субтип: 5 бит

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

Тип пакета (PT): 8 бит

Содержит код 204, который указывает на то, что это RTCP пакет APP.

Имя: 4 октета

Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для данной цели имя приложения. При этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными.

Поле информация, зависящая от приложения имеет переменную длину.

Информация, зависящая от приложения используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит.

Обработка RTCP в трансляторах

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


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

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



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

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

SDES. Трансляторы осуществляют переадресацию без изменения SDES-информации, полученной из сетевых областей, участвующих в сессии.


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

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

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

Обработка RTCP в смесителях

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

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

Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.

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

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

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

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

APP. Обработка APP-пакетов смесителями зависит от вида приложения.


Содержание раздела