Способ и система для надежного туннелирования протокола по нттр

Способ и система для надежного туннелирования протокола по нттр

Иллюстрации

Показать все

Реферат

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

[0001] Web-конференцсвязь становится все более полезным инструментальным средством для проведения онлайновых собраний, презентаций, обучающих семинаров и т.д. по Интернету или Всемирной паутине (Web). В типичной web-конференции несколько участников конференции подключаются друг к другу по Интернету со своих персональных компьютеров. Примерной программной платформой для предоставления возможностей web-конференцсвязи является MICROSOFT COMMUNICATIONS SERVER, разработанная компанией MICROSOFT Corporation, Редмонд, Вашингтон. Если клиент хочет присоединяться к онлайновому собранию, но не имеет Office Communicator, например, установленного на клиентском компьютере, клиент Communicator Web Access (CWA) на основе технологии AJAX (асинхронного JavaScript и XML) типично используется для того, чтобы предоставлять возможность клиенту присоединяться к собранию. Хотя CWA-клиент на основе технологии AJAX может присоединяться к собранию, взаимодействие с клиентом ограничивается посредством функциональности, доступной через JavaScript.

[0002] Чтобы улучшать взаимодействие при проведении собраний основывающегося на обозревателе клиента (браузера) без необходимости явной установки клиентского приложения, может быть использован тип клиента, отличный от CWA-клиента на основе технологии AJAX. Например, может быть использован клиент на основе технологии SILVERLIGHT, полученный из платформы MICROSOFT SILVERLIGHT, созданной компанией MICROSOFT Corporation, Редмонд, Вашингтон. SILVERLIGHT обеспечивает возможность разработки многофункциональных приложений, которые почти соответствуют собственным приложениям с точки зрения как функциональности, так и базового протокола, используемого для того, чтобы обмениваться данными с сервером. Тем не менее, платформа SILVERLIGHT-типа по-прежнему может иметь некоторые ограничения на возможности разрабатывать такое приложение. Например, основывающийся на обозревателе клиент типично не поддерживает сокетное соединение по протоколу управления передачей (TCP) с удаленным сервером(ами), обеспечивающее поддержку конференций по принципу web-собраний. Такие сокетные соединения запрещены вследствие усиленных функций безопасности, внутренне присущих в корпоративных сетях клиента, в которых извлечение файлов политик не допускается вследствие ограниченных портов и полной неспособности обходить брандмауэры. Действительно, ограниченные сетевые подключения существуют в таких случаях в качестве сетей, защищенных брандмауэром, сетей за прокси-серверами и т.д. Без файла политик основывающийся на обозревателе клиент отклоняет открытие сокетного соединения с удаленным сервером. Дополнительно, доступ к определенным пакетам обеспечения безопасности, таким как протокол аутентификации с помощью NT LAN Manager (NTLM), аутентификации Kerberos либо аутентификация на основе сертификатов, может быть недоступен для приложения. Без таких возможностей аутентификации основывающийся на обозревателе клиент не может быть допущен на сервер по протоколу инициирования сеанса (SIP) с использованием протокола, идентичного протоколу собственного клиента.

[0003] Хотя конкретные проблемы рассмотрены в этом разделе "Предшествующий уровень техники", это раскрытие сущности не имеет намерение каким-либо образом быть ограниченным решением этих конкретных проблем.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0004] Варианты осуществления, в общем, относятся к предоставлению полнофункционального взаимодействия при проведении собраний и улучшенной функциональности для web-клиента посредством использования серверного объекта, чтобы выступать в качестве "посредника" для соединения web-клиента с удаленной оконечной точкой, например с удаленным сервером(ами), в платформе собрания без необходимости изменений удаленного сервера(ов). Такой сервер-"посредник" упоминается, например, как "ретрансляционный сервер". Варианты осуществления тем самым предусматривают обеспечение возможности клиенту в ограниченном окружении расширять свою функциональность посредством соединения и тем самым использования функциональности ретрансляционного сервера. Ретрансляционный сервер, в свою очередь, имеет функциональность, ассоциированную со своим окружением, таким как, например, платформа Windows. Web-клиент типично использует протокол передачи гипертекста (HTTP) или протокол защищенной передачи гипертекста (HTTPS) для связи и обмена данными в web-окружении. Описание вариантов осуществления ниже ссылается на "HTTP". Тем не менее, как должны принимать во внимание специалисты в данной области техники, такие варианты осуществления включают в себя "HTTPS", когда выполняются ссылки на "HTTP". Если удаленный сервер в платформе собрания, к примеру, сервер MICROSOFT OFFICE COMMUNICATIONS ("сервер OCS"), имеет существующий протокол связи, который не основан на HTTP, например, использование ретрансляционного сервера разрешает обмен данными между web-клиентом и удаленным сервером(ами) посредством туннелирования произвольных двоичных данных или произвольных протокольных данных по HTTP между клиентом или оконечной HTTP-точкой и удаленным сервером или другим произвольным пунктом назначения. Варианты осуществления тем самым предоставляют возможность туннелирования любых произвольных данных по HTTP. Например, варианты осуществления предусматривают следующие примерные использования ретрансляционного сервера для надежного туннелирования протокола по HTTP: туннелирование любых данных по HTTP в транспортном протоколе реального времени (RTP)/защищенном транспортном протоколе реального времени (SRTP); туннелирование протокола удаленного рабочего стола (RDP) по HTTP в любом транспортном механизме (например, TCP или протокол пользовательских датаграмм (UDP)); туннелирование RDP по HTTP в RTP/SRTP; решение туннелирования SIP по HTTP и т.д.

[0005] Поскольку HTTP является простым протоколом запроса/ответа, он поддерживает несколько соединений из клиента с сервером и, следовательно, не гарантирует упорядоченную доставку сообщений запроса и ответа. Надежная доставка сообщений также не гарантируется при условии, что сообщения запроса и ответа могут быть отброшены в передаче сообщений. Например, промежуточный HTTP-прокси-сервер может отбрасывать HTTP-ответ. Надежная и упорядоченная организация и доставка сообщений являются ценными для окружения web-конференции. Также, варианты осуществления настоящего раскрытия предоставляют возможность использования идентификаторов сеансов для того, чтобы группировать запросы, которые принадлежат идентичному ретрансляционному сеансу. Дополнительно, надежная и упорядоченная доставка сообщений достигается посредством ограничения запросов одним незавершенным восходящим запросом и одним незавершенным нисходящим запросом одновременно. Варианты осуществления также предоставляют возможность использования порядковых номеров/чисел подтверждения приема для того, чтобы обеспечивать обнаружение потерянных сообщений и повторную отправку потерянных данных. Отрицательные HTTP-ответы также обрабатываются в вариантах осуществления, чтобы повторять запросы, чтобы способствовать надежной, например без потерь, передаче данных по HTTP и способности системы к восстановлению после сбоев. Помимо этого, варианты осуществления предусматривают платформенные службы в качестве части ретрансляционного сервера, при этом такие платформенные службы включают в себя, например, выполнение общих криптографических операций, операций службы доменных имен (DNS) и использование брокера аутентификации, чтобы помогать web-клиенту в вычислении обмена аутентификационными данными с пунктом назначения в окружении собрания. Далее, дополнительно, варианты осуществления предоставляют возможность системным компонентам быть подключаемыми по своему характеру и тем самым расширять функциональность web-клиента. Например, туннелирование произвольного протокола осуществляется, согласно вариантам осуществления, посредством задания подключаемого транспортного компонента на ретрансляционном сервере. Этот подключаемый транспортный компонент обеспечивает использование транспортировки по протоколу защиты транспортного уровня (TLS)/протоколу защищенных сокетов (SSL) при SIP-туннелировании, тогда как, с другой стороны, например, SRTP-транспортировка используется при RDP-туннелировании. Дополнительно, подключаемый характер компонента платформенных служб дает возможность клиенту выполнять SIP-аутентификацию с использованием брокера аутентификации в соответствии с вариантом осуществления настоящего раскрытия.

[0006] Это краткое изложение сущности изобретения предоставлено для того, чтобы представлять в упрощенной форме подбор из концепций, которые дополнительно описаны ниже в подробном описании. Это краткое изложение сущности изобретения не предназначено для того, чтобы идентифицировать ключевые или важнейшие признаки заявленного изобретения, а также не предназначено для использования таким образом, который ограничивает объем заявленного изобретения.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0007] Варианты осуществления настоящего раскрытия могут быть легко описаны в отношении прилагаемых чертежей, на которых аналогичные номера означают аналогичные элементы.

[0008] Фиг.1 иллюстрирует примерное логическое представление окружения или системы для инициирования собрания между участниками с использованием web-клиента в соответствии с вариантами осуществления, раскрытыми в данном документе.

[0009] Фиг.2 иллюстрирует примерное логическое представление окружения или системы для туннелирования произвольных двоичных данных через HTTP с использованием ретрансляционного сервера для собрания, проиллюстрированного на фиг.1, в соответствии с вариантами осуществления настоящего раскрытия.

[0010] Фиг.3 иллюстрирует логическое представление примерных функциональных компонентных модулей для туннелирования протокола по HTTP с использованием ретрансляционного сервера, проиллюстрированного на фиг.2, в соответствии с вариантами осуществления настоящего раскрытия.

[0011] Фиг.4 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, демонстрирующего взаимодействия функциональных компонентных модулей, проиллюстрированных на фиг.3, в соответствии с вариантом осуществления настоящего раскрытия.

[0012] Фиг.5 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, демонстрирующего подключаемый характер системы с использованием ретрансляционного сервера в соответствии с вариантами осуществления настоящего раскрытия.

[0013] Фиг.6 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса для группировки запросов (с помощью идентификатора сеанса), которые принадлежат ретрансляционному сеансу, в соответствии с вариантом осуществления настоящего раскрытия.

[0014] Фиг.7 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса для назначения порядковых номеров и чисел подтверждения приема запросам и ответам, чтобы обеспечивать надежную и упорядоченную доставку сообщений в соответствии с вариантом осуществления настоящего раскрытия.

[0015] Фиг.8A иллюстрирует логическое представление примерных функциональных компонентных модулей ретрансляционного сервера для туннелирования SIP-данных в соответствии с вариантами осуществления настоящего раскрытия.

[0016] Фиг.8B иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, демонстрирующего взаимодействия функциональных компонентных модулей, проиллюстрированных на фиг.8A, в соответствии с вариантом осуществления настоящего раскрытия.

[0017] Фиг.9 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса для аутентификации оконечной HTTP-точки с произвольным пунктом назначения с помощью брокера аутентификации на ретрансляционном сервере в соответствии с вариантом осуществления настоящего раскрытия.

[0018] Фиг.10 иллюстрирует логическое представление примерных функциональных компонентных модулей ретрансляционного сервера для туннелирования RDP-данных в соответствии с вариантами осуществления настоящего раскрытия.

[0019] Фиг.11 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, показывающего взаимодействия функциональных компонентных модулей, проиллюстрированных на фиг.10, в соответствии с вариантом осуществления настоящего раскрытия.

[0020] Фиг.12 иллюстрирует примерную вычислительную систему, в которой могут быть реализованы варианты осуществления настоящего раскрытия.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0021] Данное раскрытие далее подробнее описывает примерные варианты осуществления со ссылкой на прилагаемые чертежи, на которых показаны конкретные варианты осуществления. Тем не менее, другие аспекты могут быть осуществлены во многих различных формах, и включение конкретных вариантов осуществления в это раскрытие не должно быть истолковано в качестве ограничения таких аспектов вариантами осуществления, изложенными в данном документе. Наоборот, варианты осуществления, проиллюстрированные на чертежах, включаются, чтобы предоставлять раскрытие, которое является полным и завершенным и которое полностью передает намеченный объем для специалистов в данной области техники. Пунктирные линии могут быть использованы для того, чтобы показывать необязательные компоненты или операции.

[0022] Варианты осуществления, в общем, относятся к использованию ретрансляционного сервера, чтобы расширять функциональность основывающегося на обозревателе или web-технологиях клиента в окружении для проведения web-собраний. В альтернативных вариантах осуществления клиент не является основывающимся на обозревателе или web-технологиях клиентом, а наоборот, является любым типом клиента, понимаемого специалистами в данной области техники. Ретрансляционный сервер обеспечивает туннелирование произвольных двоичных данных, например, между web-клиентом или оконечной HTTP-точкой и произвольным пунктом назначения или удаленным сервером. Такое туннелирование является полезным, поскольку web-клиент типично обменивается данными с использованием HTTP-протокола и не может обмениваться данными с использованием транспортных протоколов, понимаемых посредством удаленного сервера. Такие транспортные протоколы, например, включают в себя TCP, UDP, SRTP, TLS и т.д. Эти протоколы предлагаются только в качестве примера. Любое число транспортных протоколов, как должны понимать специалисты в данной области техники, может быть использовано посредством удаленного сервера. Туннелирование любого произвольного протокола, к примеру, SIP и RDP, через HTTP тем самым предоставляется с помощью ретрансляционного сервера. Ретрансляционный сервер выступает в качестве некоторого типа "посредника", чтобы принимать байтовый буфер через HTTP-запрос и ретранслировать запрос в пункт назначения. Аналогично, ретрансляционный сервер принимает данные из пункта назначения и ретранслирует данные обратно в клиент через HTTP-ответ.

[0023] В варианте осуществления ретрансляционный сервер разрабатывается как web-приложение, размещенное, например, в информационном Интернет-сервере (IIS). Ретрансляционный сервер в таких вариантах осуществления содержит компонент управления сеансами, компонент ретрансляционной подсистемы и необязательный компонент платформенных служб. Любое число типов компонентов может быть использовано в вариантах осуществления, в комбинации или по отдельности, и некоторые компоненты, как указано, также могут быть необязательными в вариантах осуществления. Ретрансляционный сервер выполнен с возможностью быть наращиваемым, чтобы предоставлять возможность использования любого транспортного механизма для того, чтобы принимать туннелированные данные из оконечной HTTP-точки. Ретрансляционный сервер дает возможность туннелирования любых двоичных данных. Например, SIP- и RDP-трафик туннелируются в вариантах осуществления. Тем не менее, другие варианты осуществления предоставляют возможность туннелирования любых данных, включающих в себя данные передачи файлов. При установлении ретрансляционного сеанса варианты осуществления предусматривают возможность ретрансляционному серверу обмениваться данными с целевой оконечной точкой, чтобы устанавливать соединение, так что можно обмениваться конкретными протокольными данными, понимаемыми посредством целевой оконечной точки. Таким образом, ретрансляционный сервер выполнен с возможностью обмениваться данными в произвольном протоколе, чтобы устанавливать соединение.

[0024] Согласно варианту осуществления для установления ретрансляционного сеанса, клиент выполняет запрос, чтобы создавать сеанс в компоненте управления сеансами ретрансляционного сервера. Это взаимодействие между клиентом и ретрансляционным сервером может упоминаться как первая "ветвь" ретрансляционного сеанса. В вариантах осуществления ретрансляционный сервер конфигурируется с помощью необязательной платформенной службы, чтобы помогать в установлении сеанса, будь то, например, аутентификация или DNS-поиск. Ретрансляционный сервер также конфигурируется с помощью одного или более транспортных модулей, при этом транспортный модуль(и) обменивается данными с удаленным сервером в конкретном протоколе. Компонент управления сеансами управляет транспортным модулем, чтобы подключаться к удаленному серверу, с потенциальной помощью от клиента, например, через вызовы на основе web-служб. "Вызовы на основе web-служб" предлагаются только в качестве примера способов передачи этой информации. Другие типы связи, понимаемой специалистами в данной области техники, также могут быть использованы. В варианте осуществления, для первой ветви ретрансляционного сеанса, компонент управления сеансами взаимодействует с компонентом ретрансляционной подсистемы, формирует идентификатор сеанса, чтобы группировать трафик на стороне HTTP, и возвращает идентификатор сеанса в клиент. С помощью идентификатора сеанса виртуальное соединение между клиентом и ретрансляционным сервером устанавливается по HTTP. Этот идентификатор сеанса должен присутствовать в каждом HTTP-запросе, который клиент отправляет, согласно вариантам осуществления. Идентификатор сеанса, вместе с порядковыми номерами/числами подтверждения приема, принудительное требование того, что существует самое большее один незавершенный запрос согласно направлению (восходящее и нисходящее) согласно варианту осуществления, и повторение отправки HTTP-запроса предварительно заданное число раз, когда, например, возникает сбой, предоставляют способ для надежной и упорядоченной доставки двунаправленных данных между клиентом и ретрансляционным сервером по HTTP. Как отмечено выше, в вариантах осуществления это соединение является одной ветвью ретрансляционного сеанса, а вторая ветвь ретрансляционного сеанса идет из ретрансляционного сервера на удаленный сервер, в котором используется произвольный транспортный протокол. Согласно вариантам осуществления, транспортный стек загружается на ретрансляционном сервере, чтобы разрешать туннелирование протоколов.

[0025] Посредством туннелирования протокольных данных по HTTP варианты осуществления настоящего раскрытия значительно расширяют функциональность web-клиента, поскольку ретрансляционный сервер предоставляет возможность адаптации к различным и отличающимся средствам для подключения к каждой возможной целевой оконечной точке. Например, если целевая оконечная точка является сервером, различные средства используются для подключения к конкретному типу сервера, к примеру, TLS к SIP-серверу, RTP/SRTP к серверу управления совместным использованием экрана и т.д.

[0026] Дополнительно, варианты осуществления настоящего раскрытия также компенсируют ограничения, вызываемые посредством ограничивающих портов и корпоративных брандмауэров, используемых для улучшения признаков безопасности. Вследствие ограничивающих портов, присутствующих в корпоративных сетях, может быть затруднительно, если не невозможно, извлекать файл политик из web-клиента. Например, порт 943 хранит реализацию файла политик в платформе SILVERLIGHT. Клиентский компьютер на основе SILVERLIGHT отправляет запросы в web-узлы, чтобы осуществлять доступ к файлу политик на порте 943. Тем не менее, порт 943 обычно не открывается в корпоративных сетях. Следовательно, извлечение файлов политик затрудняется, если вообще не становится невозможным. Без файла политик основывающийся на обозревателе клиент отклоняет открытие сокетного соединения с удаленным сервером. Связь между web-клиентом и удаленным сервером, следовательно, нетипично невозможна. Варианты осуществления настоящего раскрытия, тем не менее, используют ретрансляционный сервер для того, чтобы соединять web-клиент и удаленный сервер. Способность ретрансляционного сервера обмениваться данными в HTTP с клиентом предоставляет возможность выполнения обхода корпоративных брандмауэров. Например, использование HTTP в качестве транспортного механизма уменьшает проблемы при обходе корпоративных брандмауэров, поскольку порты 80/443 (HTTP 80/TCP, HTTP для всемирной паутины; HTTPS 443/TCP, HTTP-протокол по TLS/SSL) типично открыты в корпоративной сети.

[0027] В вариантах осуществления web-клиент, следовательно, может открывать HTTP-соединение с ретрансляционным сервером, который выступает в качестве ретранслятора для связи между клиентом и удаленным сервером. Web-клиент затем обменивается данными с ретрансляционным сервером с использованием HTTP-запросов. После приема HTTP-запросов ретрансляционный сервер "разворачивает" фактические данные для обмена и перенаправляет их в удаленный хост с использованием транспортного протокола, понимаемого посредством удаленного сервера. Аналогично, при приеме данных в транспортном протоколе, используемом посредством удаленного сервера, ретрансляционный сервер "сворачивает" данные в HTTP-протокол и отправляет или передает их в качестве части HTTP-ответа в web-клиент.

[0028] Поскольку HTTP является простым протоколом запроса/ответа и поддерживает несколько соединений из клиента с сервером, упорядоченная доставка сообщений не гарантируется. Дополнительно, простой характер запроса/ответа HTTP-протоколов не предоставляет встроенного механизма для обеспечения надежной доставки сообщений, и, таким образом, ответы могут быть отброшены до достижения клиента. Дополнительно, эти протоколы не предоставляют способа группировать запросы, чтобы формировать сеанс. Неспособность гарантировать надежную и упорядоченную доставку сообщений мешает успешному проведению web-конференции. Также, варианты осуществления настоящего раскрытия предоставляют возможность использования идентификатора сеанса, такого как идентификатор сеанса в стиле GUID или другой криптографически строгий идентификатор, чтобы группировать запросы, которые принадлежат идентичному ретрансляционному сеансу, как пояснено выше. Идентификатор сеанса формируется произвольно на ретрансляционном сервере с использованием криптографического генератора случайных чисел. Посредством использования криптографического генератора случайных чисел исключаются угадывание числа и атака на службы, предоставляемые посредством системы, посредством третьей стороны. Для дополнительной безопасности идентификатор сеанса также может быть подписан с использованием секрета, известного только для ретрансляционного сервера, чтобы не допускать атаки на основе угадывания. Поддержка идентификаторов сеанса тем самым повышает безопасность и организует несколько соединений, внутренне присущих в HTTP-окружении, в конкретные ретрансляционные сеансы.

[0029] Чтобы дополнительно достигать упорядоченной доставки сообщений, варианты осуществления настоящего раскрытия отслеживают восходящие и нисходящие запросы с тем, чтобы давать возможность только одного незавершенного восходящего запроса и одного незавершенного нисходящего запроса одновременно. Порядковые номера и числа подтверждения приема назначаются сообщениям запроса и ответа, чтобы отслеживать обмен данными и обнаруживать потерянные сообщения. После обнаружения потерянного сообщения или приема индикатора относительно отрицательного/ошибочного HTTP-ответа (к примеру, ответа с кодом состояния, отличным от 200 OK) HTTP-запрос, соответствующий отрицательному/ошибочному HTTP-ответу, повторно отправляется и/или пробуется предварительно определенное число раз до завершения сеанса. Такое отслеживание сообщений выполнено с возможностью достигать передачи данных без потерь и способности системы к восстановлению после сбоев.

[0030] В дополнительном варианте осуществления, чтобы расширять функциональность web-клиента в ограниченном окружении для обмена данными с пунктом назначения, необязательный компонент платформенных служб помогает предоставлять функциональности, недоступные в ограниченном окружении. Когда различные протокольные данные ретранслируются, вероятно необходимы различные платформенные службы. Такие службы являются подключаемыми в систему. В качестве примера, при туннелировании SIP-данных платформенные службы включают в себя брокер аутентификации, чтобы помогать клиенту успешно отвечать на оклики системы безопасности, инициированные из SIP-сервера. Неспособность web-клиента успешно отвечать на такой оклик возникает из отсутствия достаточных программных пакетов для безопасности в ограниченной клиентской среде. Web-клиент расширяет свою ограниченную функциональность в вариантах осуществления настоящего раскрытия посредством делегирования возможностей аутентификации брокеру аутентификации, который является частью платформенных служб для туннелирования SIP-данных, хотя его использование не ограничивается туннелированием SIP-данных. Ретрансляционный сервер, в вариантах осуществления, имеет большее число функциональностей, чем ограниченная клиентская среда, поскольку он является полнофункциональным сервером. Например, ретрансляционный сервер в вариантах осуществления имеет больше установленных программных пакетов. В вариантах осуществления, когда ретрансляционный сервер отдельно не может предоставлять требуемую функциональность, платформенные службы ретрансляционного сервера могут обращаться к другим серверным компонентам, чтобы координировать удовлетворительный результат для клиента. В варианте осуществления, например, модуль брокера аутентификации на ретрансляционном сервере используется для того, чтобы помогать клиенту в вычислении обмена аутентификационными данными с пунктом назначения. Web-клиент, следовательно, делегирует криптографические вызовы ретрансляционному серверу и использует ретрансляционный сервер в качестве инструментального средства, чтобы обрабатывать криптографические вызовы и адреса, необходимые для протокольной связи на удаленном сервере. Другие варианты осуществления расширяют функциональность web-клиента посредством делегирования компоненту платформенных служб ретрансляционного сервера, например, обработки хэш-вычислений (посредством реализации необходимого алгоритма на ретрансляционном сервере) или API-вызовов для разрешения доменных имен (для разрешения имен хостов к IP-адресам). Операции, предоставляемые в данном документе, предлагаются только в качестве примера.

[0031] Примерное логическое окружение или система 100 для поддержания web-конференции между несколькими участниками показаны на фиг.1. Участники 102 и 104 хотят провести web-конференцию друг с другом. Также, клиенты 106 и 118 контактируют с сервером 110, к примеру, SIP-сервером, например, через сети 108 и 120, соответственно, чтобы запрашивать возможность присоединяться к собранию 114 и 124, соответственно. Если запросы на инициирование сеанса понимаются и активируются, SIP-сервер 110 отправляет сообщения 116 и 122 о приеме, соответственно, в клиенты 106 и 118. Тем не менее, если соединение не осуществляется между клиентом 106 и SIP-сервером 110, например, запрос на установление сеанса 114 может быть не окончательным или вообще отклонен (не показано). Такой сценарий может существовать, например, если ограниченное окружение клиента, к примеру, web-клиента 106, не допускает открытие сокетного соединения (не показано) на сервере 110. Далее, дополнительно, клиент 106 может иметь возможность обмениваться данными только в HTTP и, следовательно, не иметь возможность обмениваться данными в протоколах, понимаемых посредством сервера 110, к примеру, через TLS или TCP. Следовательно, желательно туннелировать SIP, например, по HTTP, если клиент 106 является web-клиентом, обменивающимся данными только в HTTP или имеющим некоторую другую форму ограниченных сетевых подключений, таких как корпоративные сети, защищенные брандмауэром, сети за прокси-серверами, NAT и т.д.

[0032] Хотя фиг.1 иллюстрирует общее окружение собрания, фиг.2 иллюстрирует примерное логическое окружение или систему 200 для расширения функциональности web-клиента 202 в ограниченном окружении с помощью ретрансляционного сервера 206, чтобы предоставлять полнофункциональное взаимодействие при проведении собраний с пунктом назначения 208. Web-клиент 202 также упоминается на фиг.2 как клиент туннелирования 202. Дополнительно, web-клиент может упоминаться в вариантах осуществления как любой тип произвольной оконечной точки, к примеру, "основывающийся на обозревателе клиент" и т.д. Термин "web-клиент" предлагается только в качестве примера. Если связь web-клиента 202 выполняется на основе HTTP, клиент 202 не может подключаться к целевой оконечной точке 208, если целевая оконечная точка 208 имеет существующие протоколы связи, которые не основаны на HTTP. В варианте осуществления пункт назначения 208 является удаленным сервером, к примеру, SIP-сервером. В другом варианте осуществления пунктом назначения 208 является сервер управления совместным использованием экрана. В еще других вариантах осуществления пунктом назначения 208 является сам клиент. Далее, дополнительно, может быть использовано любое число целевых оконечных точек 208, как показано посредством эллипсов 210 и пунктов назначения 212.

[0033] Клиент 202, основывающийся на web-технологиях или туннелировании, отправляет HTTP-запрос 214 по сети 204 на ретрансляционный сервер 206. Ретрансляционный сервер 206 разворачивает данные в запросе 214 и перенаправляет развернутые данные 216 с использованием протокола, понимаемого пунктом назначения 208 по сети 218, в пункт назначения 208. В вариантах осуществления ретрансляционный сервер 206 тем самым туннелирует данные, например протокольные SIP- и RDP-данные, через HTTP. Как пояснено выше, любые произвольные двоичные данные могут быть туннелированы посредством ретрансляционного сервера 206. В таком окружение при необходимости ретрансляционный сервер 206 уже имеет загруженным на него надлежащий транспортный стек, к примеру, RTP/SRTP или TLS (не показан), чтобы предоставлять такое туннелирование.

[0034] После обработки принимаемых протокольных данных 216 пункт назначения 208 отправляет протокольные данные 220 на ретрансляционный сервер 206. Ретрансляционный сервер 206 затем сворачивает данные, принятые из пункта назначения 208 в HTTP-протоколе, и отправляет их в качестве части HTTP-ответа 222 в клиент 202. Любой тип произвольных данных может быть туннелирован в соответствии с вариантами осуществления, раскрытыми в данном документе. Например, окружение или система 200 могут давать возможность: туннелирования любых данных по HTTP в RTP/SRTP; туннелирования RDP по HTTP в RTP/SRTP; туннелирования RDP по HTTP в любом транспортном механизме (к примеру, TCP или UDP); и туннелирования SIP по HTTP, согласно вариантам осуществления.

[0035] Логическое окружение 200 не ограничивается конкретными реализациями, а вместо этого осуществляет любое вычислительное окружение, в котором может осуществляться на практике функциональность окружения, описанного в данном документе. Например, любой тип клиентского компьютера 202, понимаемый специалистами в данной области техники, может быть использован в соответствии с вариантами осуществления. Дополнительно, сети 204 и 218, хотя показаны как отдельные одни сети, могут быть любыми типами сетей, традиционно понимаемых специалистами в данной области техники. В соответствии с вариантом осуществления, сеть может быть глобальной сетью (например, Интернет или всемирная паутина, т.е. "web", если коротко). Это также может быть локальная вычислительная сеть, например сеть intranet, или глобальная вычислительная сеть. В соответствии с вариантами осуществления, связь по сетям 204 и 218 осуществляется согласно одному или более стандартным форматам с коммутацией пакетов, например, H.323, IP, Ethernet и/или ATM.

[0036] Дополнительно, любое возможное окружение или система, как должны понимать специалисты в данной области техники, может быть использована в соответствии с вариантами осуществления настоящего раскрытия. Фиг.2 предлагается в качестве примера только для целей понимания идей вариантов осуществления, раскрытых в данном документе. Например, фиг.2 показывает ретрансляционный сервер 206 и пункты назначения 208, 210 и 212. Тем не менее, варианты осуществления также охватывают любой тип сервера, отдельные серверы, фермы серверов или другой сервер обмена сообщениями. Далее, дополнительно, фиг.2 показывает клиентский компьютер 202. Тем не менее, любой тип небольшого компьютерного устройства может быть использован, как должны понимать специалисты в данной области техники, без отступления от сущности и объема вариантов осуществления, раскрытых в данном документе. Хотя показан только один клиентский компьютер 202, например, другой вариант осуществления предоставляет возможность нескольким небольшим компьютерным устройствам обмениваться данными с ретрансляционным сервером 206. В варианте осуществления каждое небольшое компьютерное устройство обменивается данными с сетью 204, или, в других вариантах осуществления, несколько и отдельные сети обмениваются данными с небольшими компьютерными устройствами. В еще одном другом варианте осуществления каждое небольшое компьютерное устройство обменивается данными с отдельной сетью. Действительно, окружение или система 200 представляет допустимый способ осуществления на практике вариантов осуществления, раскрытых в данном документе, но никоим образом не имеет намерение ограничивать объем настоящего раскрытия. Дополнительно, примерное сетевое окружение 200 может рассматриваться с точки зрения конкретных описанных компонентов, например, ретрансляционного сервера, клиентского компьютера и т.д., или, альтернативно, может рассматриваться с точки зрения аналогичных модулей, соответствующих таким блокам.

[0037] Хотя фиг.2 показывает примерное окружение или систему 200 для туннелирования протокола по HTTP, фиг.3 иллюстрирует программные функциональные модули 300 для расширения функциональности основывающегося на обозревателе клиента 302 через ретрансляционный сервер 304 согласно вариантам осуществления настоящего раскрытия. Программные функциональные модули 300 выполняются в вычислительной системе, показанной на фиг.3, в соответствии с вариантами осуществления, раскрытыми в данном документе. В варианте осуществления, показанном на фиг.3, основывающийся на обозревателе клиент 302 контактирует, к примеру, через вызов 322 на основе web-служб, с ретрансляционным сервером 304, чтобы создавать ретрансляционный сеанс. Компонент 310 управления сеансами, содержащий web-службу 312, ретрансляционного сервера 304 взаимодействует, через вызовы 315 методов, например, с ретрансляционной подсистемой 314, содержащей простой web-дескриптор 316 по HTTP-протоколу, чтобы конфигурировать запрашиваемый ретрансляционный сеанс. В вариантах осуществления компонент 310 управления сеансами предоставляет функциональность для инициирования и установления соединений между клиентом 302 и пунктом назначения, к примеру, удаленным сервером 308, посредством формирования идентификаторов сеансов и т.д., для установления соединений между объектами, участвующими в собрании, например, и для группировки запросов, которые принадлежат идентичному ретрансляционному сеансу. Согласно варианту осуществления, идентификаторы сеансов в