СПОСОБ, СИСТЕМА И СЕТЕВОЙ ОБЪЕКТ ДЛЯ ПОЛУЧЕНИЯ ИНФОРМАЦИИ О ВОЗМОЖНОСТЯХ ПРОТОКОЛА ОПИСАНИЯ СЕАНСА
METHOD, SYSTEM AND NETWORK OBJECT TO OBTAIN INFORMATION ON CAPABILITIES OF SESSION DESCRIPTION PROTOCOL

Область техники
Настоящее изобретение относится к технологиям связи и, в частности, к способу, системе и сетевому объекту, предназначенным для получения информации о возможностях протокола описания сеанса.
Уровень техники
Контроллер медиашлюза (контроллер КМШ) и медиашлюз (МШ) представляют собой два ключевых компонента пакетной сети. Контроллер КМШ выполняет функцию управления вызовами, тогда как медиашлюз МШ отвечает за поддержку услуг, что позволяет отделить плоскость управления вызовами от плоскости поддержки услуг. Таким образом оптимизируется совместное использование сетевых ресурсов, упрощаются модернизация устройств и расширение обслуживания, существенно снижаются затраты на разработку и техническое обслуживание. Фиг.1 изображает примерную схему сетевого взаимодействия, иллюстрирующую применение медиашлюза МШ и контроллера КМШ в Сети Следующего Поколения (сети NGN). Связь между медиашлюзами МШ осуществляется по Транспортному Протоколу Реального Времени (протоколу RTP). Для обеспечения связи между медиашлюзом МШ и контроллером КМШ в настоящее время широко применяются Н.248/Протокол Управления Шлюзом (протокол MeGaCo) и Протокол Управления Медиашлюзом (протокол MGCP). Протокол MGCP версии 1 был разработан Рабочей Группой Проектирования Интернет (группа IETF) в октябре 1999 г. В январе 2003 г. он был усовершенствован. Протокол H-248/MeGaCo версии 1 был совместно разработан группой IETF и Международным Союзом по Телекоммуникациям (союз ITU) в ноябре 2000 г. и усовершенствован в июне 2003 г. Протокол Н.248 версии 2 был разработан союзом ITU в мае 2002 г. и усовершенствован в марте 2004 г. Протокол Н.248 версии 3 был разработан союзом ITU в сентябре 2005 г.
Если в качестве примера выбрать протокол Н.248, то различные ресурсы на медиашлюзе МШ можно абстрактно представить как оконечные элементы. Оконечные элементы можно подразделить на физические и эфемерные. К первым относятся физические оконечные элементы, которым свойственно полупостоянное существование, например канал Мультиплексной Передачи с Временным Уплотнением (передачи TDM). Ко вторым относятся некоторые общедоступные ресурсы, используемые на временной основе и освобождаемые после использования, такие как поток протокола RTP. Кроме того, весь медиашлюз МШ представляется как корневой оконечный элемент. Комбинация оконечных элементов абстрактно представляется как контекст. Контекст может содержать множество оконечных элементов. Следовательно, для описания связей между оконечными элементами используется топология. Оконечный элемент, пока не связанный с другим оконечным элементом, содержится в специальном контексте, называемом Нулевым Контекстом.
Согласно такой абстрактной модели, основанной на применении протокола, установление соединения фактически является операцией, выполняемой на оконечном элементе и контексте. Данная операция реализуется путем обмена запросами и ответами при исполнении команды между контроллером КМШ и медиашлюзом МШ. Типы команд включают в себя: Добавление (Add), Изменение (Modify), Вычитание (Subtract), Перемещение (Move), Проверка Значения (Audit Value), Проверка Возможности (Audit Capability), Уведомление (Notify) и Изменение Услуги (Service Change). Параметры команд, также называемые дескрипторами, классифицируются на основе свойств, сигналов, событий, статистики и т.д. Параметры, указывающие зависимость от услуг, логически объединяются в пакет.
В протоколе Н.248 используются локальные и удаленные дескрипторы для согласования параметров медиапотока. Локальный дескриптор определяет параметры локально принимаемого медиапотока, а удаленный дескриптор определяет параметры удаленно принимаемого медиапотока, такие как адрес получателя, порт получателя, тип медиапотока и т.д. По умолчанию, для описания этих параметров медиапотока в локальных и удаленных дескрипторах, в протоколе Н.248 используется Протокол Описания Сеанса (протокол SDP), сформулированный в документе Запрос на Комментарии (запрос RFC) 2327, разработанном группой IETF. Однако группой IETF разработан также документ RFC 3266, представляющий собой обновление документа RFC 2327 для поддержки IPv6. Кроме того, группа IETF усовершенствовала протокол SDP в недавно разработанном документе RFC 4566, что привело к изменению синтаксиса протокола.
Поскольку в протоколе Н.248 также будут применяться положения документов RFC 3266 и RFC 2566, то для реализации положений различных документов RFC, связанных с протоколом SDP, медиашлюзу МШ могут предоставляться различные возможности протокола SDP, в том числе поддерживаемые параметры протокола SDP и возможные значения этих параметров. Контроллер КМШ может эффективно использовать эти возможности для управления медиашлюзом МШ только при условии, если он располагает информацией о возможностях этих протоколов SDP. Несмотря на то что существующий в настоящее время протокол Н.248 позволяет контроллеру КМШ проверять локальный и удаленный дескрипторы на медиашлюзе МШ, он не предоставляет контроллеру КМШ никакого механизма для получения информации о возможностях протокола SDP в отношении медиашлюза МШ.
Сущность изобретения
В настоящем изобретении заявлены способы, системы, сетевые объекты, обеспечивающие получение информации о возможностях Протокола Описания Сеанса (протокола SDP). Эти способы, системы и сетевые объекты применяются для решения проблемы, заключающейся в том, что коммуникационная сторона посредством известных технологий не может получить информацию другой стороны о возможностях Протокола Описания Сеанса.
В настоящем изобретении предложен способ получения информации о возможностях Протокола Описания Сеанса, включающий:
- передачу первым сетевым объектом запроса на получение от второго сетевого объекта информации этого второго сетевого объекта о возможностях Протокола Описания Сеанса;
- и выдачу вторым сетевым объектом своей информации о возможностях Протокола Описания Сеанса первому сетевому объекту в ответ на указанный запрос.
Согласно предложенному способу информация о возможностях протокола SDP включает в себя поддерживаемый параметр протокола SDP и значение этого параметра протокола SDP.
Кроме того, первый сетевой объект взаимодействует со вторым сетевым объектом по протоколу H.248.
При использовании протокола Н.248 запрос, направляемый первым сетевым объектом второму сетевому объекту, может представлять собой проверочный командный запрос, содержащий характеристические параметры, каждый из которых соответствует одной из возможностей протокола SDP, запрашиваемой первым сетевым объектом.
Второй сетевой объект, в соответствии с указанным проверочным командным запросом, переносит свою информацию о возможностях протокола SDP, запрашиваемую первым сетевым объектом, в ответное командное сообщение на командный запрос и выдает это ответное командное сообщение первому сетевому объекту.
При использовании протокола Н.248 запрос, направляемый первым сетевым объектом второму сетевому объекту, может являться проверочным командным запросом, содержащим символ, представляющий собой запрос на получение характеристических параметров, соответствующих всем возможностям протокола SDP.
В ответ на указанный командный запрос второй сетевой объект переносит всю свою информацию о возможностях протокола SDP в ответное командное сообщение и выдает это ответное командное сообщение первому сетевому объекту.
В частном случае, ответное командное сообщение включает характеристические параметры, каждый из которых соответствует конкретной возможности протокола SDP. Информация второго сетевого объекта о возможностях протокола SDP формируется в виде значений этих характеристических параметров.
В настоящем изобретении предложена также система получения информации о возможностях протокола SDP, включающая в себя первый сетевой объект и второй сетевой объект.
Первый сетевой объект содержит запрашивающий модуль, выполненный с возможностью отправки запроса на получение от второго сетевого объекта информации этого второго сетевого объекта о возможностях протокола SDP.
Второй сетевой объект содержит отвечающий модуль, выполненный с возможностью выдачи своей информации о возможностях протокола SDP первому сетевому объекту в ответ на указанный запрос, полученный от первого сетевого объекта.
Кроме того, первый сетевой объект содержит модуль памяти, выполненный с возможностью хранения информации второго сетевого объекта о возможностях протокола SDP.
Кроме того, первый сетевой объект содержит первый приемопередающий модуль, выполненный с возможностью направления запроса.
Второй сетевой объект дополнительно содержит второй приемопередающий модуль, выполненный с возможностью приема указанного запроса и с возможностью передачи информации.
В предпочтительном случае, первый сетевой объект является контроллером медиашлюза, а второй сетевой объект - медиашлюзом. Контроллер медиашлюза и медиашлюз взаимодействуют по протоколу Н.248.
В настоящем изобретении предложен также сетевой объект. Этот сетевой объект содержит первый приемопередающий модуль и модуль, выполненный с возможностью направления запроса на получение информации однорангового коммуникационного устройства о возможностях Протокола Описания Сеанса от этого однорангового устройства через указанный первый приемопередающий модуль.
Кроме того, сетевой объект содержит модуль памяти, выполненный с возможностью хранения информации однорангового устройства о возможностях Протокола Описания Сеанса.
В настоящем изобретении предложен также другой сетевой объект. Этот сетевой объект содержит второй приемопередающий модуль и модуль, выполненный с возможностью передачи своей информации о возможностях Протокола Описания Сеанса через указанный второй приемопередающий модуль.
Преимущество предложенных в настоящем изобретении способов, систем и сетевых объектов, обеспечивающих получение информации о возможностях протокола SDP, заключается в том, что они позволяют коммуникационной стороне получать информацию о возможностях Протокола Описания Сеанса от другой стороны путем обмена сообщениями между этими двумя коммуникационными сторонами. В Частности, при использовании протокола Н.248 контроллер медиашлюза, применяя соответствующие расширенные характеристические параметры, может свободно получать от медиашлюза информацию этого медиашлюза о возможностях Протокола Описания Сеанса.
Краткое описание чертежей
Фиг.1 изображает схему сетевого взаимодействия между медиашлюзом МШ и контроллером КМШ согласно технологиям сети NGN, соответствующим известному уровню техники.
Фиг.2 иллюстрирует алгоритм, соответствующий основному варианту заявленного способа получения информации о возможностях протокола описания сеанса.
Фиг.3 иллюстрирует основную структуру заявленных системы и сетевых объектов, обеспечивающих получение информации о возможностях протокола описания сеанса.
Подробное описание
В настоящем изобретении предложен способ получения информации о возможностях протокола описания сеанса, включающий:
- передачу первым сетевым объектом запроса на получение от второго сетевого объекта информации этого второго сетевого объекта о возможностях протокола описания сеанса;
- выдачу вторым сетевым объектом своей информации о возможностях протокола описания сеанса первому сетевому объекту в ответ на указанный запрос.
Во время взаимодействия первой и второй сетей по протоколу Н.248 каждый параметр протокола SDP, определенный в документе RFC 4566, можно задавать как расширенный характеристический параметр протокола Н.248 в типе реестра Полномочного Органа по Цифровым Адресам в Интернете (органа IANA). В число этих типов параметров протокола SDP входят:
- Протокол передачи (proto)
- Тип полосы пропускания (bwtype)
- Тип сети (nettype)
- Тип адреса (addrtype)
- Ключ кодирования (enckey)
- Поле атрибута для сеансового уровня (att-filed (сеансовый уровень))
- Поле атрибута для сеансового уровня и медиауровней (att-field (и сеансовый уровень, и медиауровень))
- Поле атрибута только для медиауровня (att-filed (только медиауровень))
- Поле атрибута для неизвестного уровня (att-filed (неизвестный уровень))
Вышеуказанные характеристические параметры представляют собой значения, связанные с соответствующими типами реестра. Их типом данных является строковый список (String list), при этом указанные параметры конфигурируются в состоянии завершения и являются параметрами, доступными только для чтения.
Как показано на фиг.2, основной алгоритм реализации заявленного способа на основе протокола Н.248 включает следующие этапы.
На этапе S201 первый сетевой объект посылает проверочный командный запрос второму сетевому объекту. В проверочном командном запросе содержатся характеристические параметры, каждый из которых соответствует одной из вышеуказанных возможностей протокола SDP, запрашиваемой первой сетью.
Согласно протоколу Н.248 запрос, передаваемый от первого сетевого объекта ко второму сетевому объекту, может представлять собой проверочный командный запрос, содержащий характеристические параметры, каждый из которых соответствует одной из возможностей протокола SDP, запрашиваемой первым сетевым объектом.
В соответствии с этим проверочным командным запросом второй сетевой объект переносит свою информацию о возможностях протокола SDP, запрашиваемую первым сетевым объектом, в ответное командное сообщение на командный запрос и возвращает это ответное командное сообщение первому сетевому объекту.
При использовании протокола Н.248 запрос, передаваемый от первого сетевого объекта ко второму сетевому объекту, может также являться проверочным командным запросом, содержащим символ, представляющий собой запрос на получение характеристических параметров, соответствующих всем возможностям протокола SDP, например, запросом, содержащим подстановочный знак.
В ответ на проверочный командный запрос второй сетевой объект переносит всю свою информацию о возможностях протокола SDP в ответное командное сообщение на командный запрос и выдает это ответное командное сообщение первому сетевому объекту.
На этапе S202 второй сетевой объект переносит, согласно указанному проверочному командному запросу, свою информацию о возможностях протокола SDP, запрашиваемую первым сетевым объектом, в ответное командное сообщение на командный запрос и выдает это ответное командное сообщение первому сетевому объекту.
В частности, в ответном командном сообщении содержатся характеристические параметры, каждый из которых соответствует одной из возможностей протокола SDP, запрашиваемой первым сетевым объектом. Информация второго сетевого объекта о возможностях протокола SDP формируется в виде значений соответствующих характеристических параметров. В альтернативном случае, когда используется подстановочный знак, ответное командное сообщение содержит характеристические параметры и значения этих характеристических параметров, соответствующие всем возможностям протокола SDP, поддерживаемым вторым сетевым объектом. Значения характеристических параметров, не поддерживаемых вторым сетевым объектом, устанавливаются как пустой атрибут.
На этапе S203 первый сетевой объект локально сохраняет полученную информацию второго сетевого объекта о возможностях протокола SDP.
Один из сценариев вышеуказанного технического решения заключается в том, что первый сетевой объект является контроллером КМШ, а второй сетевой объект - медиашлюзом МШ. Обычно, чтобы определить возможности протокола SDP на медиашлюзе МШ, в том числе возможные поддерживаемые параметры протокола SDP и значения этих параметров, контроллер КМШ должен направить в медиашлюз МШ проверочный командный запрос, например командный запрос AuditValue, связанный с вышеуказанными характеристическими параметрами. Затем медиашлюз МШ может выдать контроллеру КМШ соответствующее ответное командное сообщение, содержащее значения, связанные с каждым проверяемым характеристическим параметром. Контроллер КМШ может также использовать подстановочный знак для единовременной проверки всех этих характеристических параметров. Если медиашлюз МШ не поддерживает какой-либо параметр протокола SDP, соответствующий определенному проверяемому характеристическому параметру, то медиашлюз МШ возвращает контроллеру КМШ пустой список значений, которые могут быть связаны с характеристическими параметрами. Таким образом, контроллер КМШ может получить от медиашлюза МШ информацию о возможностях протокола SDP путем проверки этих характеристических параметров.
Пакет, содержащий эти расширенные характеристические параметры, именуется пакетом возможностей протокола SDP. Характеристический параметр, соответствующий типу реестра протоколов передачи (proto), именуется протоколом передачи (proto). Характеристический параметр, соответствующий типу реестра типов адресов (addrtype), именуется типом адреса (addrtype). Контроллер КМШ направляет в медиашлюз МШ командный запрос AuditValue, относящийся к характеристическому параметру протокола передачи (proto) и характеристическому параметру типа адреса (addrtype) в пакете возможностей протокола SDP. Медиашлюз МШ вносит в список локально поддерживаемые протокол передачи RTP и протокол TCP, как возможные значения для характеристического параметра протокола передачи (proto), а также вносит в список локально поддерживаемый тип адреса IPv4, как возможное значение для характеристического параметра типа адреса (addrtype), после чего включает оба этих списка в соответствующее ответное командное сообщение для контроллера КМШ. Таким образом, контроллер КМШ может получить информацию о том, что медиашлюз МШ поддерживает тип передачи протокола RTP или протокола TCP и что медиашлюз МШ поддерживает тип адреса IPv4.
Как следует из фиг.3, настоящее изобретение также относится к системе получения информации о возможностях протокола SDP. В состав этой системы входят первый сетевой объект 300 и второй сетевой объект 400.
Первый сетевой объект 300 содержит первый приемопередающий модуль 301.
Первый сетевой объект 300 также включает в себя модуль, выполненный с возможностью отправки запросов на получение информации второго сетевого объекта 400 о возможностях протокола SDP от второго сетевого объекта 400 через первый приемопередающий модуль 301. Например, этот модуль может представлять собой запрашивающий модуль 302, показанный на фиг.3.
Первый сетевой объект 300 также содержит модуль 303 памяти, выполненный с возможностью хранения информации второго сетевого объекта 400 о возможностях протокола SDP.
Второй сетевой объект 400 содержит второй приемопередающий модуль 401.
В состав второго сетевого объекта 400 также входит модуль, выполненный с возможностью выдачи своей информации о возможностях протокола SDP через второй приемопередающий модуль 401 первому сетевому объекту 300 в ответ на запрос первого сетевого объекта 300. Например, этот модуль может представлять собой отвечающий модуль 402, показанный на фиг.3.
Вышеуказанный первый сетевой объект является контроллером медиашлюза, а второй сетевой объект - медиашлюзом. Связь между контроллером медиашлюза и медиашлюзом осуществляется по протоколу Н.248.
Специалисту данной области техники должно быть очевидно, что в настоящее изобретение могут быть внесены различные изменения, не меняющие его сущности и не выходящие за рамки приложенной формулы. Соответственно, любые модификации, замены и улучшения данного изобретения должны расцениваться как попадающие в объем его правовой охраны при условии, что они не выходят за пределы приложенной формулы.