УСТРОЙСТВО СВЯЗИ И СПОСОБ ОБХОДА БРАНДМАУЭРА ШЛЮЗА УРОВНЯ ПРИЛОЖЕНИЯ ПРИ УСТАНОВЛЕНИИ RTC-СОЕДИНЕНИЯ СВЯЗИ МЕЖДУ RTC-КЛИЕНТОМ И RTC-СЕРВЕРОМ Российский патент 2018 года по МПК H04L29/06 

Настоящее изобретение относится к способу согласно пункту 1 формулы изобретения для обхода брандмауэра (межсетевого экрана) шлюза уровня приложения при установлении RTC-соединения связи между RTC-клиентом и RTC-сервером, а также к телекоммуникационной системе согласно пункту 8 формулы изобретения, с помощью которой может быть выполнен упомянутый способ. Настоящее изобретение также относится к соответствующему компьютерному программному продукту согласно пункту 6 формулы изобретения и к машиночитаемому носителю данных согласно пункту 7 формулы изобретения, на котором сохранен компьютерный программный продукт.

Настоящее изобретение относится в целом к обходу брандмауэра шлюза уровня приложения (в дальнейшем, как правило, упоминается кратко как ʺбрандмауэрʺ), иными словами, к шлюзованию пакетов данных с помощью такого брандмауэра, например, для связи в соответствии с Voice Over IP (другими словами VoIP) (передача голоса по Интернет-протоколу (IP)) или Video over IP (передача видео по IP). Эти методы связи относятся к так называемой связи по транспортному протоколу реального времени (Real-time-Transport-Protocol, RTP-связи). Последующее описание исходит, без ограничения общности, из конкретного случая применения этой RTC-связи (RTC=Real Time Communications - связь в реальном времени), а именно WebRTC-связи, которая осуществляется через веб-браузер.

Брандмауэры с давних пор являются препятствием для связи по протоколу VoIP или Video over IP. Причиной этого являются динамически согласованные в VoIP-стандартах (H.323, SIP[RFC3261], …) номера UDP-портов (User Datagram Protocol - протокола пользовательских дейтаграмм) для RTP голосовых или видео пакетов (RTP=Real-Time Transport Protocol - транспортный протокол реального времени, см. [RFC3550]).

С помощью точно специфицированных стандартных протоколов сигнализации (H.323/H.245 (H.323 использует H.245 для согласования медиа-данных), SIP/SDP (Session Initiation Protocol/Session Description Protocol - протокол установления сеанса/протокол описания сеанса), XMPP/Jingle (Extensible Messaging and Presence Protocol -расширяемый протокол обмена сообщениями и информацией о присутствии), MGCP (Media Gateway Control Protocol - протокол управления медиа-шлюзом) [RFC3435] и т.д.) производители брандмауэров имеют возможность, за счет реализации определенных разделов протоколов (тех разделов сигнализации, которые релевантны для согласования номеров UDP-портов), осуществлять динамически совместное считывание. Тем самыми брандмауэр устанавливается в состояние, чтобы открывать и закрывать динамически согласованные UDP-порты для передаваемых голосовых/видео-RTP-пакетов. Этот известный принцип также упоминается как брандмауэр шлюза уровня приложения (Firewall Application Layer Gateway, ALG- брандмауэр, далее также кратко брандмауэр).

В связи с тем, что протокол сигнализации для WebRTC не стандартизирован, каждый производитель может использовать свой собственный, проприетарный (фирменный) протокол, или он может, в качестве альтернативы, основываться на известных протоколах. В итоге, у производителей ALG-брандмауэров возникает проблема, состоящая в том, что они не могут полагаться на фиксированный протокол сигнализации, как было бы в случае, например, SIP/SDP, и поэтому не могут его проверить, чтобы найти данные портов в сообщениях сигнализации.

Для лучшего понимания, ниже со ссылкой на фиг. 5 кратко описано обход ALG-брандмауэра, как это до сих пор возможно для ʺSIP через WebSockets (сочетание IP-адреса и номера порта)ʺ. Сначала, браузер 22 посылает сообщение N01 ʺHTTP-запросʺ ("HTTP request" ) на веб-сервер 32, который отвечает на него сообщением N02 ʺHTTP-ответʺ (HTTP response") на функциональный блок 24 (для JavaScript/HTML5), благодаря чему устанавливается HTTP-соединение. Для процедуры обновления, более конкретно, в сообщении N91, которое WebRTC-клиент 20 посылает на WebSockets-сервер 34 как ʺWebSockets запрос обновленияʺ ("WebSockets Upgrade Request") от НТТР-соединения к WebSockets-соединению, согласуется применение SIP между WebRTC-клиентом 20 и WebSockets-сервером 34. Таким образом, брандмауэр 40 оповещается о том, что используется SIP. При этом также можно согласовывать и другие стандартизированные протоколы, например, XMPP (XMPP применяет не SDP, а Jingle. Jingle является соответствующим XMMP-расширением, которое разрешает RTC), Н.323, MGCP. После приема ответа обновления в виде сообщения N92 от WebSockets-сервера 34, WebRTC-клиент 20 посылает сообщение N93 на WebRTC-сервер 30, после чего брандмауэр 40 отыскивает SDP-данные на основе известных SIP/XMPP-структур и открывает соответствующие RTP-порты. Это согласование квитируется соответствующим сообщением N94 от WebRTC-сервера 30 к WebRTC-клиенту 20 с помощью SDP-ответа. Затем может производиться обмен медиа-данными, при этом применяются другие протоколы, такие как RTP (Real-time Protocol -протокол реального времени), STUN (утилиты прохождения сессии для NAT, Session Traversal Utilities for NAT NAT=Network Address Translation - преобразование сетевых адресов), ICE (Interactive Connectivity Establishment - интерактивная установка соединения).

WebSockets-протокол опционально содержит поле, которое идентифицирует применяемый протокол сигнализации (здесь, например, SIP). Это представлено, в частности в информационном блоке 14 под ʺзапрос браузераʺ -"Browser Request") и ʺответ веб-сервераʺ - "Web-Server Response").

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

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

Есть несколько известных технологий брандмауэра для WebRTC, которые обсуждаются для обхода брандмауэра для WebRTC:

а. Как и для SIP или H.323, определенные для WebRTC области UDP-порта в брандмауэре могут также оставаться постоянно открытыми. Однако это часто нежелательно для компаний с ограничительными требованиями по безопасности.

b. HTTP (Hypertext Transfer Protocol - протокол передачи гипертекста) туннелирование: Брандмауэры часто имеют один порт всегда открытым. Это TCP-порт 80 (TCP= Transmission Control Protocol -протокол управления передачей), через который также проходит HTTP-трафик данных [см. RFC2616] (TCP/http-порт). Идея заключается в том, чтобы установить TCP-туннель между WebRTC-клиентом WebRTC и TURN-сервер (TURN=Traversal Using Relays around NAT - обход с использованием ретрансляторов вокруг NAT, NAT=Network Address Translation - преобразование сетевых адресов [см. RFC5766]) на другой стороне брандмауэра („TURN access via TCP - ʺTURN-доступ через TCPʺ) и использовать его, чтобы шлюзовать UDP/RTP-голосовые/видео пакеты и пакеты данных через брандмауэр. Некоторые брандмауэры/компании являются настолько ограничительными, что они принимают HTTP-трафик не от любого клиента, а только от определенного внутреннего сервера (HTTP-прокси). В этом случае WebRTC-браузер с использованием известного метода HTTP-CONNECT [RFC2817] должен поручить HTTP-прокси установить вышеупомянутый TCP-туннель через брандмауэр, чтобы использовать его позже для TURN-протокола. В еще одном варианте текущего обсуждения, например в IETF, может применяться ʺTURN over WebSocketsʺ-туннель через брандмауэр [draft-chenxin-behave-turn-WebSocket].

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

- WebRTC-клиент (браузер) реализовал описанные признаки (например, HTTP CONNECT). В связи с этим, имеет место зависимость от производителей браузеров (Google, Microsoft, Mozilla, …). Для мобильных WebRTC-клиентов, таких как смартфоны, планшеты (native WebRTC-App - родных WebRTC-приложений) в настоящее время необходимо реализовать саму процедуру,

- компания создала и поддерживает необходимую инфраструктуру (HTTP-прокси),

- WebRTC-поставщик решения создал TURN-сервер как часть своего решения за брандмауэром.

с. Протокол управления брандмауэром/портом [RFC6887] (например, Cisco). Идея заключается в том, что WebRTC-клиент перед отправкой голосового или видео пакета выдает поручение брандмауэру посредством собственного протокола открыть определенный UDP-порт. Протоколы управления брандмауэром известны примерно с 2003 г. Однако на практике этот подход до сих пор не внедрен, что обусловлено, среди прочего, озабоченностью по поводу безопасности, аутентификации, авторизации. Компании (CIO, IT-отдел) не хотят зачастую допускать ʺуправлениеʺ их брандмауэрами множеством клиентов или серверов.

d. Мультиплексирование порта: При таком подходе, некоторые или все RTP-потоки WebRTC-вызова (например, все аудио и видео потоки одного вызова) вплоть до всех RTP-потоков некоторых или всех вызовов всей системы передаются через единственный UDP-порт. Такой подход облегчает проблему порта брандмауэра за счет того, что требуется меньше ресурсов порта, но не решает основную проблему преодоления ограничительного брандмауэра. Кроме того, не каждый производитель WebRTC-клиентов или серверов будет поддерживать (опционально) мультиплексирование порта во взаимодействии с системами на основе SIP/XMPP/H.323. Мультиплексирование порта является, в частности, опцией для производителей WebRTC-решений с большими и вплоть до очень больших требований масштабирования (например, общественные, абонентские службы, такие как Google, …).

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

Эта задача решается посредством - обычно реализуемого компьютером - способа согласно пункту 1 формулы изобретения, компьютерной программы или компьютерного программного продукта согласно пункту 6 формулы изобретения, машиночитаемого носителя согласно пункту 7 формулы изобретения, на котором хранится компьютерный программный продукт, и телекоммуникационной системы согласно пункту 8 формулы изобретения. Предпочтительные варианты осуществления изобретения являются объектом зависимых пунктов формулы изобретения.

В соответствии с изобретением RTC-клиент и RTC-сервер договариваются тогда, когда должно быть установлено RTC-соединение связи, что осуществляется, например, при открытии веб-страницы через НТТР-запрос, с применением проприетарного (т.е. нестандартизированного) RTC-протокола сигнализации, о том, какие из портов ALG-брандмауэра потребуются, чтобы иметь возможность передавать пакеты данных, которые требуются для RTC-соединения связи, за счет того, что они в контексте, то есть в качестве составной части, проприетарного RTC-протокола сигнализации применяют по меньшей мере один стандартизированный элемент сообщения, с помощью которого можно найти те данные, которые относятся к применяемым портам. Брандмауэр не имеет специальных знаний проприетарного RTC-протокола сигнализации и учитывает при установлении RTC-соединения связи с применением стандартизованного элемента сообщения, какие из портов брандмауэра согласовывались RTC-клиентом и RTC-сервером, то есть оказались необходимыми для того, чтобы передавать через RTC-соединение связи обмениваемые пакеты данных. Другими словами, брандмауэр может ʺподслушиватьʺ, какие порты необходимы, и, таким образом, брандмауэр может динамически открывать и закрывать необходимые порты в соответствии с результатом согласования между RTC-клиентом и RTC-сервером.

Элемент сообщения в протоколе связи является синтаксическим сегментом одного или нескольких сообщений сигнализации, в которых кодируется информация, которая оценивается в сетевых компонентах и/или оконечных телекоммуникационных системах связи в рамках связанных с коммутацией процессов. В элементах сообщения различаются стандартизированные элементы и специфические для производителя (проприетарные) элементы; последние не являются существенными для базовых функций сети связи и обычно игнорируются сетевыми компонентами и/или оконечными устройствами других производителей. Соответствующий изобретению стандартизованный элемент сообщения включает в себя идентифицирующие данные о соединениях, которые устанавливаются для передачи медиа-данных от и к оконечному устройству и соответственно должны направляться брандмауэром, например, путем открытия порта, в направлениях передачи и приема. Дополнительные пояснения таких элементов сообщения содержатся в ЕР 1317150 А2.

Соответствующий изобретению способ решает, таким образом, основную задачу, другими словами, тем, что в качестве составной части RTC-канала сигнализации применяется расширение, которое позволяет брандмауэру прослушивать, какие порты или UDP-порты динамически согласовываются для обмена голосовых и/или видео пакетов, и, таким образом, динамически открывать и закрывать соответствующие UDP-порты для RTP-трафика. При этом упомянутый контекст может создаваться во время установления RTC-канала сигнализации, во время RTC-сигнализации или после RTC-сигнализации в форме дополнительного поля, которое содержит информацию, которая применяется для последующего нахождения RTР-портов RTP в сообщениях сигнализации. Установление или стандартизация того расширения, которое определяет контекст для RTC-сегмента сигнализации, который при считывании брандмауэром достаточен, чтобы обеспечивать возможность управления UDP/RTP-портами, то есть открытия и закрытия, обозначается в последующем как WebRTC-сигнализация или кратко как WebRTCSig.

Соответствующий изобретению способ, таким образом, предоставляет ряд преимуществ:

- не требуется реализация протоколов управления брандмауэром, которые представляли бы собой высокие барьеры с точки зрения требований безопасности;

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

- в сценариях, при которых не может применяться решение на основе HTTP-туннелирования, соответствующий изобретению способ является относительно простой и несмотря на это надежно реализуемой альтернативой, которая может способствовать значительному распространению WebRTC; путем использования настоящего изобретения могут, например, реализовываться решения для брандмауэра, чтобы обеспечивать, в частности, для некоторых WebRTC-приложений сквозное решение;

- соответствующее изобретению решение также может быть стандартизировано простым способом, например, через IETF, так что может быть осуществлена общая реализация, которая открыта для всех производителей решений с WebRTC-поддержкой и WebRTC-брандмауэров.

В случае использования протокола безопасных веб-сокетов (Secure WebSockets Protocol - WSS) -то есть WebSockets-соединения с использованием TLS (Transport Layer Security - безопасности транспортного уровня) - брандмауэр может без труда считывать содержащиеся в WebRTC-соединении более высокие компоненты WebRTC-сигнализации, причем для этой проблемы, например, может служить применение TLS-контекста последовательности скачков (ретрансляционных участков) в качестве метода решения, как оно выполняется аналогично в пограничных контроллерах сессий (Session Border Controller- SBC). ALG-брандмауэр завершает TLS, то есть шифрование следует только до или от брандмауэра. TLS и без того действует только на ретрансляционных участков. ALG-брандмауэр, таким образом, имеет одну TLS-связь с одной стороны с WebRTC-клиентом (или прокси) на одной стороне ALG-брандмауэра и другую TLS-связь с WebRTC-сервером (или Access Node - узлом доступа) на другой стороне ALG-брандмауэра.

Согласно предпочтительному варианту осуществления изобретения, для согласования необходимых портов, то есть обмена данными и параметрами относительно RTC-сигнализации, между RTC-клиентом и RTC-сервером применяется один из предварительно определенных (произвольно пронумерованных) типов сигнализации, обмен которым после первоначального установления НТТР-соединения производится между RTC-клиентом и RTC-сервером с помощью так называемого ʺWebRTCSig-квитированияʺ- “WebRTCSig-Handshake). При этом предпочтительный вариант заключается в том, что WebRTCSig-квитирование выполняется как часть процедуры обновления с HTTP-соединения на WebSockets-соединение и устанавливает контекст для RTC-сигнализации. Для этого, возможно, потребуются расширения WebSockets-протокола, для чего, например, специальное или определенное - как правило, дополнительное - поле вставляется в заголовок. В качестве альтернативы, WebRTCSig-квитирование может осуществляться только после того, как HTTP-соединение переключилось (или соответственно обновилось) на WebSockets-соединение, что осуществляется посредством собственного протокола, который предпочтительно включает в себя лишь несколько дополнительных байтов и обозначается также как ʺпротокол тонкого уровняʺ - "Thin Layer Protocol") или соответственно ʺWebRTCSig over WebSocketsʺ. Что касается последней альтернативы WebRTCSig-квитирования, только после процедуры обновления, первая упомянутая альтернатива WebRTCSig-квитирования как часть процедуры обновления предоставляет преимущество, состоящее в том, что по времени экономится одно двойное прохождение в прямом и обратном направлениях. Что касается точных моментов времени или временных характеристик (тайминга), WebRTCSig-квитирование происходит, например, после того как RTC-клиент загрузил JavaScript (JS-клиент) с RTC-сервера.

Собственно WebRTCSig-информация, в зависимости от RTC-протокола сигнализации, может включать в себя, например, следующие варианты протоколов сигнализации:

1) WebRTCSig Тип 1=SIP и SDP over WebSockets

2) WebRTCSig Тип 2=XMPP и Jingle over WebSockets

3) WebRTCSig Тип 3=ʺПроприетарная WebSockets-сигнализация с вложенным SDP (смещение)ʺ

Т.е., WS-сообщения сигнализации (WS=WebSockets) с сообщениями SDP-протокола (например, WS Setup (установка) с SDP Offer (предложение); WS Connect (соединение) с SDP Answer (ответ)). Для того чтобы брандмауэр нашел начало сообщения SDP-запрос/ответ (SDP-Offer/Answer), может/должно сообщаться значение смещения, которое адресует начало SDP-сообщения запроса.

Следует отметить, что SDP в качестве сигнализации сессии подходит по двум причинам:

а) API WebRTC-браузера (стандартизирован W3C (Консорциумом World Wide Web)) в версии 1 основан на SDP.

b) SDP является протоколом описания сеанса в SIP.

В качестве примерного стандартизованного элемента сообщения в RFC 3264 указывается модель запроса-ответа со строкой ʺm=video 53000 RTP/AVP 32ʺ, которая означает, что видео должно передаваться через порт 53000.

Таким образом, SDP облегчает, с одной стороны, взаимодействие с SIP-средой, а с другой стороны, взаимодействие клиентской стороны между сигнализацией сеанса и WebRTC-API.

Если производитель применяет проприетарный протокол сигнализации, он будет, весьма вероятно, использовать SDP с проприетарными сообщениями, потому что WebRTC-API также применяет SDP. В соответствующей изобретению WebRTCSig типа 3, например, в качестве дополнительной данные будет совместно сигнализироваться, что ALG-брандмауэр должен начинаться с байта 77 и должен интерпретироваться как SDP-протокол (потому что это в свою очередь стандартизировано). Все, что находится перед ним, то есть до байта 76 включительно, является частью ʺпроприетарного сообщения установкиʺ.

Альтернативно, браузер может отображать SDP WebRTC-API также на что-то другое - например, H.245, Jingle или проприетарный формат - и применяться для RTC-сигнализации. Это будет тогда характеризоваться другим типом WebRTCSig. Этот вариант соответствует предпочтительному развитию соответствующего изобретению способа, в соответствии с которым применяется протокол сигнализации с сообщением сигнализации, при котором применяется сообщение запроса протокола описания сеанса с вложенным смещением, причем смещение адресует начало этого сообщения.

4) WebRTCSig тип 4=Явный SDP-протокол

Можно явно стандартизировать SDP-протокол для WebRTC.

5) WebRTCSig тип 5=Согласованные порты с соответствующим изобретению, предопределенным и сообщенным синтаксисом.

6) WebRTCSig тип 6=Согласованные порты в RESTful-Style (соответствующие ограничениям REST) (REST= Representational State Transfer - передача состояния представления): известный URI (Uniform Resource Identifier - универсальный идентификатор ресурса) с определенной (под-)структурой, которая содержит порты.

7) WebRTCSig тип 7=Согласованные порты, в RESTful Style: известный URI, который включает в себя указатель, который указывает на ресурс (сервер), от которого следует получать порты.

Эти последние два варианта, в свою очередь, соответствуют предпочтительному развитию соответствующего изобретению способа, по которому в сообщениях RTC-сигнализации согласованные порты определяются в RESTful-стиле.

8) WebRTCSig тип 8=Текстовая строка вставляется в качестве параметра, характеризующего начало SDP в сообщениях сигнализации. Сама строка является произвольной, она не должна только встречаться еще раз в остальной части сообщения.

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

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

IETF не будет, согласно текущему пониманию, стандартизировать полный WebRTC-протокол сигнализации, как это было сделано для SIP или H.323. Поэтому ALG-брандмауэр должен реализовывать WebRTC-протоколы сигнализации всех производителей WebRTC-приложений, если необходимо динамически понимать протоколы сигнализации во всех средах, чтобы находить согласованные UDP-порты, на которых передаются собственно RTP-пакеты. Этого можно избежать за счет того, что выбранные протоколы сигнализации группируются по категориям (т.е., например, произвольно нумеруются). Если ALG-брандмауэр обнаруживает или считывает, что речь идет о WebRTC-сигнализации типа 1, то он знает, что ему нужно выполнять синтаксический анализ SIP/SDP. Однако если ALG-брандмауэр считывает, что применяется WebRTC-сигнализация типа 3 со смещением 77, то ALG-брандмауэр знает, что он должен синтаксически анализировать сообщение с байта 77 как SDP-протокол и т.д. WebRTC-сигнализация типа 4 будет тогда представлять собой SDP-протокол от байта 1. WebRTC-сигнализация типа 5 плюс явное указание UDP-порта источника и места назначения будет точно сообщать ALG-брандмауэру UDP-порты, причем в этом случае не применяется SDP-протокол.

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

Фиг. 1 - схематичное изображение варианта осуществления соответствующей изобретению телекоммуникационной системы,

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

Фиг. 5 - блок-схема последовательности операций для известного способа обхода брандмауэра.

Телекоммуникационная 10 система, показанная на фиг. 1, в соответствии с настоящим изобретением включает в себя RTC-клиент 20, RTC-сервер 30 и брандмауэр 40. Обмен сообщениями между брандмауэром 40 с клиентом 20 с одной стороны и сервером 30 с другой стороны обозначен несколькими стрелками. Кроме того, схематично показано, что брандмауэр 40 имеет несколько портов, которые чисто схематично обозначены с помощью P1, P2 и P3. Брандмауэр 40 включает в себя устройство 42 управления, например, CPU или группу процессоров, которая реализует функции брандмауэра 40. Кроме того, схематично показан CD-ROM 90 в качестве примера носителя данных, на котором сохранена компьютерная программа или компьютерный программный продукт 92, причем носитель 90 данных с соответствующей компьютерной программой 92 предоставлен устройству 42 управления, чтобы реализовывать соответствующий изобретению способ.

Фиг. 2 представляет первый вариант осуществления соответствующего изобретению способа для обхода брандмауэра, с помощью которого реализуется RTC-сигнализация типа 3 в соответствии с вышеприведенным объяснением. Сначала браузер 22 посылает сообщение N01 ʺHTTP-запросʺ ("HTTP request" ) на веб-сервер 32, на которое тот отвечает сообщением N02 ʺHTTP-ответʺ-"HTTP response") на функциональный блок 24 (для JavaScript/HTML5), посредством чего устанавливается НТТР-соединение. Затем функциональный блок 24 посылает в ходе процедуры WebSockets-обновления соответствующее сообщение N11 на WebSockets-сервер 34 в веб-сервере 32, причем сообщение N11 содержит тип WebRTC-сигнализации и SDP_Offset- маркер. WebSockets-сервер 34 подтверждает процедуру обновления WebRTC-клиенту 20 сообщением N12. Наконец, WebRTC-клиент 20 посылает на WebRTC-сервер сообщение N13, которое содержит информацию о том, что сообщение сигнализации начинается с SDP-смещением 255. Таким образом, брандмауэр 40 находит SDP с байта 255. Посредством соответствующего сообщения N14 от WebRTC-сервера 30 к WebRTC-клиенту 20 - оба из которых используют протокол запроса/ответа - завершается сигнализация посредством маркировки SDP_Offset. Посредством этого типа сигнализации брандмауэр 40 может ʺсчитыватьʺ, где можно найти релевантную для него информацию (здесь с байта 255). Эта информация передается в новом поле заголовка, в котором указывается тип и SDP_Offset, как отмечено в информационном блоке 11 под заголовком ʺзапрос браузераʺ ("Browser Request") в последней строке. Как указано в информационном блоке 11 под заголовком ʺответ Web-сервераʺ ("Web Server response") в последней строке, WebRTC-сервер 30 подтверждает WebRTC-клиенту 20, что согласованным типом сигнализации является № 3, и дает знать с помощью ʺOKʺ, что сигнализация осуществляется с согласованной маркировкой SDP_Offset.

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

После успешного завершения сигнализации, медиа-данные могут передаваться через 40 брандмауэр, для чего используются другие протоколы, такие как RTP (протокол реального времени), STUN (утилиты прохождения сессии для NAT, NAT=Network Address Translation - преобразование сетевых адресов), ICE (Interactive Connectivity Establishment - интерактивная установка соединения ).

Как упоминалось выше, в соответствии с изобретением передается тип WebRTC-сигнализации (в данном примере, тип соответствует - произвольно распределенному - № 3), и в месте с обозначением SDP_Offset находится текстовая строка, которая маркирует указатель на SDP в сообщениях сигнализации. Сама строка является произвольной, она не должна только еще раз встречаться в остальной части сообщения. Вместо указанного в примере обозначения ʺSDP_Offsetʺ, могла бы, например, также случайная последовательность символов достаточной длины удовлетворить этому требованию.

Второй, показанный на фиг. 3, вариант осуществления соответствующего изобретению способа отличается от первого варианта осуществления тем, что в процедуре обновления к WebSockets-соединению с сообщениями N21 и N22 передается другой тип сигнализации (в данном примере 5), а также значения портов, которые должен открыть брандмауэр 40. Другими словами, сообщение сигнализации N23 содержит компоненты, которые в данном примере обозначены как ʺOpen_Ports: 62255, 62256, 31234, 31235ʺ, соответственно, и затем следует сообщение подтверждения N24. Соответственно, брандмауэр 40 открывает соответствующие порты. В новом поле заголовка, таким образом, записывается тип сигнализации № 5, а также указание ʺOpen_Portsʺ. На последнем месте находится текстовая строка, которая маркирует RTP-порты для медиа в сообщениях сигнализации. Текстовая строка, как таковая, хотя и произвольная, но не должна повторяться в остальной части сообщения. Вместо указанного в информационном блоке 12 под заголовком ʺзапрос браузераʺ-"Browser Request") в последней строке примера ʺOpen_Portsʺ, могла бы, например, также случайная последовательность символов достаточной длины удовлетворять этому требованию. Соответствующим образом, ответ WebRTC-сервера 30 WebRTC-клиенту 20 содержит подтверждение согласованного типа сигнализации № 5, а также (опциональное) подтверждение того, что порты открыты (см. также информационный блок 12). Таким образом, осуществляется сигнализация со значениями портов.

Показанной на фиг. 4 третий вариант осуществления соответствующего изобретению способа отличается от двух предыдущих тем, что в процедуре обновления к WebSockets-соединению с сообщениями N31 и N32 передается другой тип WebRTC-сигнализации, а именно, № 8, а также текстовая строка, которая маркирует начало SDP в сообщениях сигнализации N33 и N34. Таким образом, брандмауэр 40 обнаруживает, что используется неизвестный протокол с вложенным SDP, и отыскивает текстовую строку ʺHere_starts_SDPʺ (здесь начинается SDP) и открывает те RTP-порты, которые содержались в SDP. Это приводит к тому, что во вновь введенном поле заголовка в качестве типа сигнализации указывается № 8, и текстовая строка ʺHere_starts_SDPʺ в ʺзапросе браузераʺ ("Browser Request") включена в соответствии с информационным блоком 13. Кроме того, соответствующий ответ WebRTC-сервера 30 WebRTC- клиенту 20 содержит, таким образом, (в сообщении N34) согласованный тип 8 сигнализации, а также подтверждение того, что сигнализация осуществляется с SDP_Start_String (строкой начала SDP). Вместо указанной в качестве примера текстовой строки ʺHere_starts_SDPʺ могла бы также применяться другая случайная последовательность символов достаточной длины, если она не повторяется в остальной части сообщения.

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

Перечень ссылочных позиций

10 телекоммуникационная система

11-14 информационный блок

20 (Web)RTC-клиент

22 браузер

24 функциональный блок

30 (Web)RTC-сервер

32 веб-сервер

34 WebSockets-сервер

40 брандмауэр

42 устройство управления

90 носитель данных

92 компьютерный программный продукт

N01-N94 сообщение

P1-P3 порт

Изобретение относится к средствам обхода брандмауэра шлюза уровня приложения при установлении RTC-соединения связи между RTC-клиентом и RTC-сервером. Технический результат заключается в обеспечении обхода брандмауэра, удовлетворяющего всем требованиям безопасности. RTC-клиент и RTC-сервер согласовывают при установлении RTC-соединения связи, какие из портов брандмауэра необходимы для пакетов данных, обмениваемых по RTC-соединению связи, при этом они применяют в качестве составной части проприетарного RTC-протокола сигнализации по меньшей мере один стандартизованный элемент сообщения, с помощью которого могут отыскиваться те данные, которые относятся к портам, подлежащим применению. Брандмауэр обнаруживает при установлении RTC-соединения связи с помощью стандартизованного элемента сообщения, какие из портов брандмауэра были согласованы RTC-клиентом и RTC-сервером в качестве необходимых для пакетов данных, обмениваемых по RTC-соединению связи, и брандмауэр открывает и закрывает необходимые порты динамически в соответствии с результатом согласования. 5 ил., 3 н. и 4 з.п. ф-лы.

1. Способ обхода брандмауэра (40) шлюза уровня приложения при установлении RTC-соединения связи между RTC-клиентом (20) и RTC-сервером (30) с применением проприетарного RTC-протокола сигнализации, причем брандмауэр (40) не имеет конкретных сведений о проприетарном RTC-протоколе сигнализации,

включающий в себя следующие этапы:

- RTC-клиент (20) и RTC-сервер (30) согласовывают при установлении RTC-соединения связи, какие из портов (P1, P2, P3) брандмауэра (40) необходимы для пакетов данных, обмениваемых по RTC-соединению связи, при этом они применяют в качестве составной части проприетарного RTC-протокола сигнализации по меньшей мере один стандартизованный элемент сообщения, с помощью которого могут отыскиваться те данные, которые относятся к портам, подлежащим применению,

- брандмауэр (40) обнаруживает при установлении RTC-соединения связи с помощью стандартизованного элемента сообщения, какие из портов (P1, P2, P3) брандмауэра (40) были согласованы RTC-клиентом (20) и RTC-сервером (30) в качестве необходимых для пакетов данных, обмениваемых по RTC-соединению связи, и

- брандмауэр (40) открывает и закрывает необходимые порты (P1, P2, P3) динамически в соответствии с результатом согласования.

2. Способ по п. 1, отличающийся тем, что для согласования необходимых портов (Р1, Р2, Р3) применяют определенный вариант протокола сигнализации, который после установления транспортного соединения сигнализации обменивается между RTC-клиентом (20) и RTC-сервером (30) с помощью RTC-сигнализации.

3. Способ по п. 2, отличающийся тем, что обмен вариантом протокола сигнализации происходит как часть процедуры обновления НТТР-соединения на WebSockets-соединение.

4. Способ по п. 3, отличающийся тем, что для обмена вариантом протокола сигнализации применяют расширения в WebSockets-протоколе, в частности, определенное поле в заголовке.

5. Способ по п. 2, отличающийся тем, что обмен вариантом протокола сигнализации осуществляют только после выполнения процедуры обновления НТТР-соединения на WebSockets-соединение с применением собственного протокола.

6. Машиночитаемый носитель (90) данных, содержащий сохраненную на нем компьютерную программу (92), которая при исполнении предписывает устройству (42) управления осуществлять соответствующий изобретению способ по любому из пп. 1-5.

7. Телекоммуникационная (10) система, в которой возможен обход брандмауэра (40) шлюза уровня приложения при установлении RTC-соединения связи между RTC-клиентом (20) и RTC-сервером (30) с применением проприетарного RTC-протокола сигнализации, причем брандмауэр (40) не имеет конкретного знания о проприетарном RTC-протоколе сигнализации, содержащая:

- RTC-клиент (20)

- RTC-сервер (30) и

- брандмауэр (40) с множеством портов (Р1, Р2, Р3),

отличающаяся тем, что брандмауэр (40) имеет устройство (42) управления для осуществления способа по любому из пп. 1-5.