Алгоритмы мультимедиа

Интерфейс маршрутизации RSVP

Реализация RSVP нуждается в следующей поддержке со стороны механизма маршрутизации узла.

• Запрос маршрута

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

  Ucast_Route_Query( [ SrcAddress, ] 
      DestAddress, Notify_flag ) > OutInterface
  Mcast_Route_Query( [ SrcAddress, ] 
     DestAddress, Notify_flag ) > [ IncInterface, ] OutInterface_list

  В зависимости от протокола маршрутизации запрос может зависеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, который является также IP-адресом источника сообщения. IncInterface характеризует интерфейс, через который ожидается прибытие пакета. Некоторые мультикастные протоколы маршрутизации могут не выдавать этот адрес. Когда флаг Notify_flag = True, блок маршрутизации отправит сообщение о непреднамеренном изменении маршрута, если такое изменение произойдет.

  Мультикастный маршрутный запрос может вернуть пустой список OutInterface_list, если за оговоренным маршрутизатором нет ни одного получателя. Запрос маршрутной информации может вернуть сообщение No such route — такой маршрут отсутствует, возможно, в результате временной рассогласованности (например, сообщение Path или PathTear для запрошенного маршрута не дошло). В любом случае локальное состояние должно быть актуализовано так, как это требуется в запросе, который не может быть переслан далее.
• Сообщение об изменении маршрута

  При маршрутном запросе с флагом Notify_flag = True процесс маршрутизации может послать асинхронное сообщение процессу RSVP, который уведомляет об изменении определенного маршрута.

  Ucast_Route_Change( ) > [ SrcAddress, ] 
     DestAddress, OutInterface Mcast_Route_Change( ) > [ SrcAddress, ] 
        DestAddress, [ IncInterface, ] OutInterface_list
• Выявление списка интерфейсов

  RSVP должен быть способен запоминать, какой реальный и виртуальный интерфейсы являются активными, а также их IP-адреса.

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

Пакетные I/O интерфейсы RSVP

Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.

• Неизбирательный режим приема сообщений RSVP

  Пакеты, полученные для IP-протокола (код 46), но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP, переправляемые таким образом, включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46.

  В маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами идентификация интерфейса (реального и виртуального), через который получено заданное сообщение, так же, как IP-адрес источника и TTL, с которым оно получено, должна быть доступна для процесса RSVP.
• Спецификация выходного канала

  RSVP должен уметь обеспечить посылку дейтограммы через специальный выходной интерфейс (реальный или виртуальный) в обход обычного механизма маршрутизации. Виртуальным каналом может быть, например, мультикастный туннель.
• Спецификация адреса источника и TTL

  RSVP должен быть способен специфицировать IP-адрес отправителя и TTL, которые могут использоваться при посылке сообщений Path.
• Оповещение маршрутизатора

  RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert).

Манипуляции, зависящие от вида услуг

Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Чтобы манипулировать этими объектами, процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг.

• Сравнение спецификаций потоков

  Compare_Flowspecs( Flowspec_1, Flowspec_2 ) > result_code

  Возможный результат операции result_codes указывает: flowspecs равны, Flowspec_1 меньше, Flowspec_2 больше, flowspecs совместимы и можно вычислить LUB, или flowspecs не совместимы. Заметим, что, сравнивая две спецификации, мы косвенно сопоставляем Tspecs, которые они содержат. Хотя процесс RSVP не может сам осуществить разбор flowspec с целью извлечения Tspec, он может использовать вызов процедуры Compare_Flowspecs для косвенного вычисления Resv_Te.
• Сравнение LUB Flowspecs

  LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) > Flowspec_LUB
• Вычисление GLB Flowspecs

  GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) > Flowspec_GLB
• Сравнение Tspecs

  Compare_Tspecs( Tspec_1, Tspec_2 ) > result_code

  Возможным результатом процедуры result_codes может быть: Tspecs равны или Tspecs не равны.
• Сумма Tspecs

  Sum_Tspecs( Tspec_1, Tspec_2 ) > Tspec_sum

  Этот вызов используется для вычисления Path_Te.

10.6. Протокол запуска сессий SIP

Протокол SIP (Session Initiation Protocol) описан в документе RFC-3261, (смотри также [10.6] и The Internet Protocol Journal V6, N1, March 2003, William Stallings, "The Session Initiation Protocol") и служит для запуска, модификации и завершения сессий реального времени между партнерами IP-сети. SIP может поддерживать как моно-, так и мультимедийные приложения, включая видеоконференции.

Протокол SIP является лишь одним из протоколов, которые обеспечивают мультимедийный обмен через Интернет. SIP представляет собой сигнальный протокол, который позволяет одному партнеру послать запрос другому и согласовать параметры мультимедиа-сессии.

Собственно транспортировка мультимедиа-данных обычно осуществляется с помощью протокола RTP (RealTime Transport Protocol).

Базовым стимулом создания протокола SIP являлась необходимость реализации работы с VoIP (Voice over IP). Протокол поддерживает пять аспектов, сопряженных с установлением и завершением мультимедийных коммуникаций.

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

Доступность пользователя. Предполагается проверка готовности парнера-адресата участвовать в коммуникациях.

Возможности пользователя. Определяются параметры среды, которые должны быть использованы.

Формирование сессии. Создается соединение точка-точка или сессия с несколькими партнерами при заданных коммуникационных параметрах.

Управление сессией. Предполагается создание и завершение сессий, модификация параметров сессии и сервисов.

SIP базируется на модели транзакций, сходных с запросами/откликами в протоколе HTTP. Каждая транзакция состоит из запроса клиента, который включает в себя определенный метод, или функцию, для сервера и, по крайней мере, один отклик. SIP использует большинство полей заголовков, правил кодирования и кодов статуса протокола HTTP. Это позволяет работать с данными легко читаемого и отображаемого формата. SIP применяет протокол SDP (Session Description Protocol), который с помощью набора типов данных, специфизированных в MIME (Multipurpose Internet Mail Extensions), определяет содержимое сессии.

Компоненты и протоколы SIP

Система, использующая SIP, может рассматриваться как состоящая из клиентов, серверов и индивидуальных сетевых элементов. RFC-3261 определяет клиента и сервер следующим образом.

Клиент. Клиент является субъектом сети, который посылает SIP-запросы и получает SIP-отклики. Клиенты, если это требуется, могут непосредственно взаимодействовать с человеком. Агент пользователя клиента и прокси являются клиентами.

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

Индивидуальные элементы стандартной конфигурации включают в себя:

Агент пользователя. Резидентно присутствует в каждой конечной станции SIP. Он выполняет две роли:

Агент пользователя клиента UAC (User Agent Client): посылает запросы SIP. Агент пользователя сервера UAS (User Agent Server): получает SIP-запросы, генерирует отклики, принимает, отклоняет или перенаправляет запросы.

Сервер переадресации. Используется во время инициализации сессии, чтобы определить адрес запрашиваемого устройства. Сервер переадресации отсылает полученную информацию устройству, инициировавшему запрос, направляя UAC, который может применяться для контакта с альтернативным URI (Universal Resource Identifier). URI является универсальным идентификатором, используемым для именования любого ресурса в Интернет. URL, предназначенное для Web-адресов, имеет тип URI. Подробнее это рассмотрено в RFC-2396[1].

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

Регистратор. Является сервером, который принимает запросы REGISTER и помещает информацию, которую он получает (SIP-адрес и ассоциированный IP-адрес регистрирующего устройства) из этих запросов, в службу локализации для домена, который обслуживает.

Служба локализации. Используется серверами переадресации SIP или прокси, чтобы получить информацию о возможном положении источника запроса. Для этой цели служба локализации поддерживает базу данных SIP-адресов/ IP-адресов.

В RFC-3261 в качестве логических устройств определены различные серверы. Они могут быть использованы в качестве отдельных серверов в Интернет или могут объединяться в рамках одного приложения, которое работает резидентно на определенном физическом сервере.

Рис. 10.34. Протоколы и компоненты SIP

На рис. 10.34 показано, как некоторые SIP компоненты связаны друг с другом и с протоколами, которые они применяют. Агент пользователя А использует SIP для установления сессии с другим агентом пользователя B, который выступает в роли сервера. Диалог запуска сессии пользуется SIP и включает один или более прокси серверов, чтобы переадресовать запросы и отклики между двумя агентами пользователя. Агенты пользователя работают также с протоколом SDP (Session Description Protocol), который служит для описания медийной сессии.

Прокси серверы могут, если это требуется, работать в качестве серверов переадресации. Система DNS (Domain Name System) является важной частью, реализующей протокол SIP. Обычно, UAC осуществляет запрос, используя доменное имя UAS, а не IP-адрес. Прокси сервер вынужден консультироваться у DNS-сервера, чтобы найти прокси сервер для зоны места назначения.

Из эксплуатационных соображений SIP часто работает поверх UDP (User Datagram Protocol), и обеспечивает свои собственные механизмы обеспечения надежности доставки, но может использовать и TCP. Если необходим безопасный или криптографический транспортный механизм, сообщения SIP могут передаваться посредством протокола TLS (Transport Layer Security).

С протоколом SIP ассоциирован SDP, описанный в RFC-2327 [10.4]. SIP применяется для приглашения одного или более партнеров для участия в сессии, в то время как кодированные SDP тела сообщений содержат информацию о типе медиа-данных (например, голос, видео). После того как эта информация отправлена и подтверждена, все участники знают IP-адреса, доступную полосу и тип данных. Затем начинается передача информации, с применением соответствующего транспортного протокола. Обычно используется RTP. Во время сессии участники, с помощью сообщений SIP, могут изменить параметры сессии, такие, как новые медиа-типы или новые участники сессии.

Универсальные локаторы ресурсов SIP

Ресурсы в конфигурации SIP идентифицируются URI. Примерами ресурсов могут служить:

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

URI SIP имеют формат, базирующийся на формате адресов email, в частности user@domain. Существует две общие схемы. Обычные URI имеют форму:

sip:ааа@itep.com

URI могут также включать пароль, номер порта и сопряженные параметры. Если требуется безопасная передача, sip: заменяется на sips:. В последнем случае сообщения SIP передаются с привлечением протокола TLS.

Примеры работы

Спецификация SIP достаточно сложна; главный документ, RFC-3261, содержит 269 страниц. Для пояснения работы протокола рассмотрим несколько примеров.

На рис. 10.35 показана успешная попытка пользователя А установить сессию с пользователем B, чье URI bbb@itep.com. [10.9] UAC А сконфигурирован для работы с прокси сервером (выходной сервер) в своем домене и начинает работу с посылки сообщения INVITE прокси серверу, которое указывает на намерение подключить к сессии UAS (1); сервер подтверждает получение запроса (2). Хотя UAS B определяется его URI, выходной прокси сервер должен учесть возможность того, что B в данный момент недоступен или что B поменял адрес. Соответственно, выходной прокси сервер должен переадресовать запрос INVITE прокси серверу, который ответственен за домен itep.com. Выходной прокси сервер, таким образом, консультируется с локальным серером DNS, чтобы получить IP-адрес прокси сервера itep.com (3), путем запроса ресурсной записи DNS SRV, которая содержит информацию о прокси для домена itep.com.

Рис. 10.35.

DNS-сервер откликается (4) отправкой IP-адреса прокси сервера itep.com. Прокси сервер А может теперь переадресовать сообщение INVITE выходному прокси серверу (5), который посылает подтверждение сообщения (6). Входной прокси сервер теперь консультируется с сервером локализации для определения адреса B (7), а сервер локализации откликается посылкой адреса B, что позволяет послать ему сообщение SIP (8).

Прокси сервер может теперь отослать сообщение INVITE B (9). Посылается отклик от B к А (10, 11, 12), в то время как UAS B обращается к локальному медийному приложению (например, телефонии). Когда медиа-приложение воспринимает вызов, UAS B посылает отклик OK А (13, 14, 15).

Наконец, UAC А посылает сообщение подтверждения UAS B, чтобы подтвердить получения окончательного отклика (16). В этом примере, ACK посылается непосредственно от А к B, обходя два прокси. Это происходит потому, что конечные точки уже знают адрес своего партнера из обмена INVITE/200 (OK). Медиа-сессия началась, А и B могут обмениваться данными через одно или более RTP-соединения.

Рис. 10.36.

В следующем примере (рис. 10.36) используется два типа сообщений, которые пока еще не входят в стандарт SIP, но описаны в документе RFC-2848 [5] и вероятно будут включены в последующие версии SIP. Эти типы сообщений поддерживают телефонные приложения. Предположим, что в предыдущем примере А была проинформирована о том, что B недоступен. UAC А может выдать сообщение SUBSCRIBE (1), указывающее, что он хочет быть проинформирован, когда B будет доступен.

Этот запрос будет переадресован в нашем случае через два прокси к серверу PINT (Public Switched Telephone Network [PSTN]Internet Networking – общедоступную коммутируемую телефонную сеть) (2, 3). Сервер PINT работает как шлюз между IP-сетью, из которой пришел запрос установить телефонное соединение, и телефонной сетью, которая осуществляет соединение с адресатом. В этом примере мы предполагаем, что логика сервера PINT совмещена со службой локализации. Может также случиться, что B подключен к Интернет, а не к PSTN, — в этом варианте нужна система, эквивалентная логике PINT, чтобы обрабатывать запросы SUBSCRIBE. Мы здесь предполагаем также, что функциональность PINT встроена в службу локализации. Служба локализации авторизует подписку, прислав сообщение OK (4), которое передается А (5, 6). Служба локализации затем немедленно посылает сообщение NOTIFY с текущим статусом B (7, 8, 9), которое подтверждается UAC А (10, 11, 12).

На рис. 10.37 показано продолжение обмена. B подключается к системе локализации, послав сообщение REGISTER прокси серверу своего домена (1). Прокси обновляет базу данных службы локализации, отражая факт регистрации (2). Обновление подтверждается прокси (3), что подтверждает регистрацию B (4). PINT воспринимает новый статус B от сервера локализации и посылает сообщение NOTIFY, содержащее новый статус B (5). Это сообщение переадресуется А (6, 7). UAC А подтверждает получение уведомления (8, 9, 10).