JP6359184B2 - Ｒｔｃクライアントとｒｔｃサーバとの間のｒｔｃ通信コネクションを確立するときにアプリケーションレイヤ・ゲートウェイ・ファイアウォールをトラバースするための通信装置および方法 - Google Patents

Description

本発明は、ＲＴＣクライアントとＲＴＣサーバとの間のＲＴＣ通信コネクションを確立するときにアプリケーションレイヤ・ゲートウェイ・ファイアウォールをトラバースするための請求項１記載の方法、および上述の方法を実施可能な請求項８記載の通信装置に関する。さらに本発明は、請求項６記載の対応するコンピュータプログラム製品、およびこのコンピュータプログラム製品が記憶されている請求項７記載の機械読み取り可能な記憶媒体にも関する。

本発明はごく一般的には、アプリケーションレイヤ・ゲートウェイ・ファイアウォール（以下では通例、略して「ファイアウォール」と称する）のトラバースに関するものであり、換言すれば、たとえばＶｏｉｃｅ ｏｖｅｒ ＩＰ （ＶｏＩＰ）またはＶｉｄｅｏ ｏｖｅｒ ＩＰによる通信のための、上述のファイアウォールを介したデータパケットの通過に関する。これらの通信形態は、いわゆるリアルタイム転送プロトコル通信（ＲＴＰ通信）に属する。一般性を狭めるものではないが、以下の説明は、上述のようなＲＴＣ通信（ＲＴＣ ＝ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）の特別な適用事例に基づくものであり、つまりＷｅｂブラウザを介して行われるＷｅｂＲＴＣ通信に基づくものである。

ファイアウォールはかなり以前から、ＶｏＩＰまたはＶｉｄｅｏ ｏｖｅｒ ＩＰを介した通信の伝達にとっては障害物である。その理由は、ＲＴＰ音声パケットまたはビデオパケット（ＲＴＰ ＝ Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ， ［ＲＦＣ３５５０］参照）に対し、ＶｏＩＰ標準（Ｈ．３２３， ＳＩＰ［ＲＦＣ３２６１］， ．．．）においてＵＤＰポート番号（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が動的に取り決められることにある。

厳密に指定された標準シグナリングプロトコル（Ｈ．３２３／Ｈ．２４５（Ｈ．３２３はメディアデータの取り決めのためにＨ．２４５を用いる）、ＳＩＰ／ＳＤＰ （Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）， ＸＭＰＰ／Ｊｉｎｇｌｅ （Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）， ＭＧＣＰ （Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ［ＲＦＣ３４３５］等）を用いて、ファイアウォールメーカーは、（ＵＤＰポート番号の処理に関連するシグナリングパートの）特定のプロトコルパートの実装により、動的な読み出しが可能である。これによってファイアウォールは、動的に取り決められるＵＤＰポートを、伝送すべき音声／ビデオのＲＴＰパケットのために開放および閉鎖することができるようになる。このような公知の基本方式は、ファイアウォール・アプリケーションレイヤ・ゲートウェイ（＝ＡＬＧファイアウォール、以下では略してファイアウォール）とも称する。

ＷｅｂＲＴＣのためのシグナリングプロトコルは標準化されていないことから、各メーカーはそれぞれ独自のプロプライエタリなプロトコルを用いてもよいし、または各メーカーは別の選択肢として、公知のプロトコルに基づき構築してもよい。しかしながら結局のところ、ＡＬＧファイアウォールのメーカーにとって問題になるのは、たとえばＳＩＰ／ＳＤＰの場合であれば当てはまるように、１つの決められたシグナリングプロトコルに基づき構築することはできず、したがってシグナリングメッセージにおいてポート情報を見つけるために、それを検査できないことである。

理解を深めるために、次に図５を参照しながら、これまで「ＷｅｂＳｏｃｋｅｔを介したＳＩＰ」のために実現されているような、ＡＬＧファイアウォールのトラバースについて概略的に説明する。最初にブラウザ２２は、メッセージＮ０１「ＨＴＴＰリクエスト」をＷｅｂサーバ３２に送信し、Ｗｅｂサーバ３２は（ＪａｖａＳｃｒｉｐｔ／ＨＴＭＬ５用の）ファンクションユニット２４へのメッセージＮ０２「ＨＴＴＰレスポンス」によって、メッセージＮ０１に対して応答し、これによってＨＴＴＰコネクションが確立される。アップグレード手順において、正確に言えば、ＷｅｂＲＴＣクライアント２０がＷｅｂＳｏｃｋｅｔサーバ３４へ、ＨＴＴＰコネクションからＷｅｂＳｏｃｋｅｔコネクションへの「ＷｅｂＳｏｃｋｅｔアップグレードリクエスト」として送信するメッセージＮ９１において、ＷｅｂＲＴＣクライアント２０とＷｅｂＳｏｃｋｅｔサーバ３４との間でＳＩＰの使用について取り決めが行われる。このようにしてファイアウォール４０は、ＳＩＰが使用されることを識別する。この場合、当然ながら、他の標準化プロトコルの取り決めも可能であり、たとえばＸＭＰＰ（ＸＭＰＰはＳＤＰではなくＪｉｎｇｌｅを使用する。Ｊｉｎｇｌｅは、ＲＴＣを許容するＸＭＰＰのそれ相応の拡張である）、Ｈ．３２３， ＭＧＣＰなどの取り決めも行うことができる。ＷｅｂＳｏｃｋｅｔサーバ３４からメッセージＮ９２としてアップグレードレスポンスを受信した後、ＷｅｂＲＴＣクライアント２０は、メッセージＮ９３をＷｅｂＲＴＣサーバ３０へ送信し、これに応答してファイアウォール４０は、既知のＳＩＰ／ＸＭＰＰ構造に基づきＳＤＰデータをサーチし、対応するＲＴＰポートを開放する。この取り決めは、対応するメッセージＮ９４を用いてＷｅｂＲＴＣサーバ３０からＷｅｂＲＴＣクライアント２０へ、ＳＤＰレスポンスにより確認応答される。その後、メディアデータを交換することができ、この交換にあたり、他のプロトコルたとえばＲＴＰ （Ｒｅａｌｔｉｍｅ Ｐｒｏｔｏｃｏｌ）、ＳＴＵＮ （Ｓｅｓｓｉｏｎ Ｔｒａｖｅｒｓａｌ Ｕｔｉｌｉｔｉｅｓ ｆｏｒ ＮＡＴ， ＮＡＴ ＝ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）， ＩＣＥ （Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）などが用いられる。

ＷｅｂＳｏｃｋｅｔプロトコルには、使用されるシグナリングプロトコル（この例ではＳＩＰ）を識別するフィールドがオプションとして含まれている。このことは特に、情報欄１４内において「ブラウザリクエスト」と「Ｗｅｂサーバレスポンス」の下に挙げられている。

これに関連してＷｅｂＲＴＣによる問題点は、ＷｅｂＲＴＣのためのシグナリングプロトコルが標準化されていない、ということである。つまりＷｅｂＲＴＣサーバがＷｅｂＲＴＣクライアントとのシグナリング通信をどのように処理するのかは、ＷｅｂＲＴＣサーバ各々に課されている。ＷｅｂＲＴＣにおける独自のないしはプロプライエタリなシグナリングアプローチによって、ファイアウォールメーカーは、ファイアウォールをトラバースもしくは横断するための一般的なＡＬＧファイアウォールソリューションいわゆるＷｅｂＲＴＣトラバーサルを、実現することができない。このことによって、ＷｅｂＲＴＣソリューションの進展において問題が引き起こされる可能性がある。

ＷｅｂＲＴＣは、商業的なアプリケーションがようやくスタートしたところである。ただしその際に前提とすることができるのは、ＷｅｂＲＴＣがＷｅｂベースのリアルタイム通信の最も有力な技術になる、ということである。

ＷｅｂＲＴＣのために複数のファイアウォール技術が知られており、それらの技術をＷｅｂＲＴＣのためのファイアウォールトラバーサルについて説明する。

ａ．たとえばＳＩＰまたはＨ．３２３の場合のように、ＷｅｂＲＴＣのために定められたファイアウォールのＵＤＰポート領域についても、持続的に開放することができる。ただしこのことは、セキュリティ要求の厳格な企業にとっては望ましくない。

ｂ．ＨＴＴＰ （Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）トンネリング：この場合、ファイアウォールはたいてい、１つのポートを常時開放している。このポートはＴＣＰ−Ｐｏｒｔ ８０ （ＴＣＰ ＝ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）であり、このポートを介してＨＴＴＰデータトラフィック［ＲＦＣ２６１６参照］も伝送される（ＴＣＰ／ｈｔｔｐポート）。この着想は、ＷｅｂＲＴＣクライアントとＴＵＲＮサーバ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙｓ ａｒｏｕｎｄ ＮＡＴ， ＮＡＴ ＝ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ， ［ＲＦＣ５７６６］参照）との間のＴＣＰトンネルを、ファイアウォールの他方の側に構築する、というものであり（"ＴＵＲＮ ａｃｃｅｓｓ ｖｉａ ＴＣＰ"）、ファイアウォールを介してＵＤＰ／ＲＴＰ音声／ビデオパケットとデータパケットを通過させるためにこれが用いられる。多くのファイアウォール／企業は、任意のどのようなクライアントからのＨＴＴＰトラフィックも容認するのではなく、特定の内部サーバ（ＨＴＴＰプロキシ）から到来したもののみを容認する、というように制約されている。このケースでは、ＷｅｂＲＴＣブラウザは、公知のＨＴＴＰ−ＣＯＮＮＥＣＴ方式［ＲＦＣ２８１７］を用いてＨＴＴＰプロキシに対し、ファイアウォールを通過する上述のＴＣＰトンネルを構築するよう依頼して、それをあとからＴＵＲＮプロトコルのために使用できるようにする。たとえばＩＥＴＦにおいて目下議論中のさらに別の形態によれば、ファイアウォールを通過する"ＴＵＲＮ ｏｖｅｒ ＷｅｂＳｏｃｋｅｔｓ"トンネルを用いることができる［ｄｒａｆｔ−ｃｈｅｎｘｉｎ−ｂｅｈａｖｅ−ｔｕｒｎ−ＷｅｂＳｏｃｋｅｔ］。

ＨＴＴＰトンネリングのこのようなソリューションは、基本的に実現可能であるが、連続的な使用を可能にするためには、様々な前提条件を満たさなければならない。この場合、以下のことが保証されていなければならない。すなわち、
・ＷｅｂＲＴＣクライアント（ブラウザ）は、既述の特徴を実装済みである（たとえばＨＴＴＰ ＣＯＮＮＥＣＴ）。この点については、ブラウザメーカー（Ｇｏｏｇｌｅ， Ｍｉｃｒｏｓｏｆｔ， Ｍｏｚｉｌｌａ， ．．）に左右される。スマートフォンやタブレットなどのモバイルＷｅｂＲＴＣクライアント（ネイティブＷｅｂＲＴＣアプリケーション）のためには、目下のところこの方法を自分で実装しなければならない。
・企業は、必要とされるインフラストラクチャを構築済みであり、サポートしている（ＨＴＴＰプロキシ）。
・ＷｅｂＲＴＣソリューションプロバイダは、そのソリューションの一部分としてＴＵＲＮサーバをファイアウォールの後方に設置済みである。

ｃ．ファイアウォール／Ｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ［ＲＦＣ６８８７］（たとえばＣｉｓｃｏ）。この着想は、ＷｅｂＲＴＣクライアントが音声パケットまたはビデオパケットを送信する前に、所定のＵＤＰポートを開放するよう、独自のプロトコルでファイアウォールに依頼する、というものである。ファイアウォールコントロールプロトコルは、約２００３年頃から知られている。ただし実際には、このアプローチは定着しておらず、その理由とは特に、セキュリティ、認証、権限に関して懸念があることによる。企業（ＣＩＯ、ＩＴセクション）の多くは、自身のファイアウォールを多数のクライアントまたはサーバによって「制御」させることを望んでいない。

ｄ．ポート多重化：このアプローチによれば、１つのＷｅｂＲＴＣ呼のうちの複数またはすべてのＲＴＰストリーム（たとえば１つの呼のすべての音声ストリームおよびビデオストリーム）から、システム全体の複数またはすべての呼のＲＴＰストリーム全体に至るまで、単一のＵＤＰポートを介して伝送することができる。このアプローチは、僅かなポートリソースしか必要としないことから、ファイアウォールのポートの問題を軽減するが、制約のあるファイアウォールをまずは乗り越える、という基本的な問題点を解決するものではない。さらに、ＷｅｂＲＴＣクライアントまたはＷｅｂＲＴＣサーバのどのようなメーカーであっても、ＳＩＰ／ＸＭＰＰ／Ｈ．３２３ベースのシステムと共働してポート多重化をサポートするわけではない（オプション）。ポート多重化は特に、大規模なスケーリング要求から極めて大規模なスケーリング要求を伴うＷｅｂＲＴＣソリューションのメーカーのためのオプションである（たとえば公衆サービス、在宅サービス、たとえばＧｏｏｇｌｅなど）。

したがって本発明の課題は、上述の欠点を克服し、あらゆるセキュリティ要求を充足する一方で、容易に取り扱うことのできる、ファイアウォールのトラバース方法を提供することである。さらに本発明の課題は、かかる方法を実施可能な相応の通信装置を提供することである。

この課題は、（一般にコンピュータによって実現される）請求項１記載の方法、請求項６記載のコンピュータプログラムもしくはコンピュータプログラム製品、このコンピュータプログラム製品が記憶されている請求項７記載の機械読み取り可能なデータ媒体、さらに請求項８記載の通信装置によって解決される。従属請求項には、本発明の有利な実施形態が記載されている。

本発明によれば、たとえばＨＴＴＰリクエストを介してＷｅｂサイトを開くときに行われるようなＲＴＣ通信コネクションの確立が望まれるとき、ＲＴＣクライアントとＲＴＣサーバは、プロプライエタリな（つまり標準化されていない）ＲＴＣシグナリングプロトコルを用いて、ＲＴＣ通信コネクションのために必要とされるデータパケットを伝送できるようにする目的で、ＡＬＧファイアウォールのいずれのポートが必要とされるのか、についての取り決めを行う。この取り決めにおいて、ＲＴＣクライアントとＲＴＣサーバは、プロプライエタリなＲＴＣシグナリングプロトコルのコンテキストにおいて、つまりこのようなプロトコルの構成部分として、使用すべきポートに関する情報を見つけ出すことのできる少なくとも１つの標準化されたメッセージ要素を使用する。ファイアウォールは、プロプライエタリなＲＴＣシグナリングプロトコルの固有の情報を有しておらず、ＲＴＣ通信コネクションの確立にあたり、ＲＴＣ通信コネクションを介して交換すべきデータパケットを伝送できるようにする目的で、ファイアウォールのいずれのポートがＲＴＣクライアントとＲＴＣサーバとによって取り決められたのかを、つまり必要であるとみなされたのかを、標準化されたメッセージ要素を使用して検出する。換言すれば、ファイアウォールは、いずれのポートが必要とされるのかを「聞き取る」ことができ、したがってファイアウォールは、ＲＴＣクライアントとＲＴＣサーバとの取り決め結果に従って、必要とされるポートを動的に開放および閉鎖することができる。

通信プロトコルにおけるメッセージ要素は、１つまたは複数のシグナリングメッセージの構文上の１セクションであり、そのセクション内には、通信ネットワークのネットワークコンポーネントおよび／または端末機器において交換技術的なプロセス中に評価される情報が符号化されている。メッセージ要素において、標準化された要素とメーカー固有の（プロプライエタリな）要素とが区別される。メーカー固有の要素は、通信ネットワークの基本機能にとって必要不可欠なものではなく、他のメーカーのネットワークコンポーネントおよび／または端末機器は通常、それらの要素を無視する。本発明による標準化されたメッセージ要素には、端末機器からのおよび端末機器へのメディアデータの伝達のために構築されるコネクションに関して識別を行う情報が含まれており、これに応じてファイアウォールはこのコネクションを、たとえばポートのイネーブルなどによって送信方向および受信方向で通過させなければならない。この種のメッセージ要素についてのさらに詳しい説明は、欧州特許出願公開第１３１７１５０号明細書（ＥＰ １ ３１７ １５０ Ａ２）を参照されたい。

したがって換言すれば本発明による方法は、基礎を成す問題点を以下のようにして解決するものである。すなわち、交換すべき音声パケットおよび／またはビデオパケットのためにいずれのポートもしくはいずれのＵＤＰポートが動的に取り決められるのかを、ファイアウォールがＲＴＣコネクション構築においてリスニングできるようにし、つまりはＲＴＰトラフィックのために対応するＵＤＰポートを動的に開放および閉鎖できるようにする拡張が、ＲＴＣシグナリングチャネルの構成部分として用いられる。この場合、上述のコンテキストは、ＲＴＣシグナリングチャネルの構築中、ＲＴＣシグナリング中、またはＲＴＣシグナリングに続いて、シグナリングメッセージ内であとでＲＴＰポートを見つけ出すために用いられる情報を含む付加的なフィールドの形態で、形成することができる。ファイアウォールによる読み取りにあたり、ＵＤＰ／ＲＴＰポート制御つまりは開放および閉鎖の実現に十分であるコンテキストを、ＲＴＣシグナリングパートに対して定義する拡張の設定もしくは標準化を、以下ではＷｅｂＲＴＣシグナリングと称し、または略してＷｅｂＲＴＣＳｉｇとも称する。

これらのことから、本発明による方法によって以下の複数の利点が得られる。すなわち、
・セキュリティ要求について高いハードルとなってしまうファイアウォールコントロールプロトコルの実装が不要である。
・ファイアウォールにおけるポートを、またはそれどころかポートの領域を、持続的に開放状態に維持しておく必要がない。このように開放状態に維持しておくのは、セキュリティ上の理由から危険な状況となるおそれがある。ここで付言しておくと、複数またはすべてのＵＤＰストリームがただ１つのＵＤＰポートを介して伝送されるポート多重化技術が、おそらくは将来、まずは大規模なソリューションのメーカーによってサポートされることが見込まれる。
・ＨＴＴＰトンネリングをベースとするソリューションを適用できない状況において、本発明による方法は比較的簡単でありながら確実に実現可能な選択肢であり、これによってＷｅｂＲＴＣの急速な普及が促進される可能性がある。本発明による方法を使用することによってたとえば、特に所定のＷｅｂＲＴＣアプリケーションに対し持続的なソリューションを提供できるようにするための、ファイアウォールソリューションを実現することができる。
・しかも本発明による解決手段を、たとえばＩＥＴＦを介するなどして簡単に標準化することができ、したがってＷｅｂＲＴＣベースのソリューションおよびＷｅｂＲＴＣファイアウォールのすべてのメーカーにとってオープンな汎用的な実装を実現できるようになる。

セキュアなＷｅｂＳｏｃｋｅｔプロトコル（ＷＳＳ）、すなわちＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）を介したＷｅｂＳｏｃｋｅｔコネクション、が使用される場合、ファイアウォールは、ＷＳＳコネクションに含まれる比較的高位のＷｅｂＲＴＣシグナリングパートをそのままでは読み取ることができない。この問題に対処するためにたとえば、ＴＬＳホップバイホップ・コンテキストの使用がソリューションアプローチとして役立つ可能性があり、これはセッションボーダコントローラ（ＳＢＣ）の場合と同様に実施される。ＡＬＧファイアウォールはＴＬＳを終了させ、すなわち暗号化はファイアウォールまでしか、もしくはファイアウォールからしか行われない。ＴＬＳは、いずれにせよホップバイホップであるにすぎない。したがってＡＬＧファイアウォールは、一方ではＡＬＧファイアウォールの一方の側におけるＷｅｂＲＴＣクライアント（またはプロキシ）までのＴＬＳリンクと、ＡＬＧファイアウォールの他方の側におけるＷｅｂＲＴＣサーバ（またはアクセスノード）とのＴＬＳリンクとを有している。

本発明の１つの有利な実施形態によれば、ＲＴＣクライアントとＲＴＣサーバとの間で、必要とされるポートを取り決めるために、つまりＲＴＣシグナリングに関する情報とパラメータを交換するために、予め定義された（任意にナンバリングされた）複数のシグナリングタイプのうちの１つが用いられる。このようなシグナリングタイプは、ＲＴＣクライアントとＲＴＣサーバとの間でＨＴＴＰコネクションが最初に確立された後、いわゆる「ＷｅｂＲＴＣＳｉｇハンドシェーク」によって交換される。その際、１つの有利な実施形態によれば、ＷｅｂＲＴＣＳｉｇハンドシェークは、ＨＴＴＰコネクションからＷｅｂＳｏｃｋｅｔコネクションへのアップグレード手順の一部分として実施され、ＲＴＣシグナリングに対するコンテキストを生成する。このために場合によっては、ＷｅｂＳｏｃｋｅｔプロトコルの拡張が必要とされ、そのような拡張のためにたとえば、ヘッダ内の特別なもしくは定義された（通常は付加的な）フィールドが用いられる。これに対する代替案として、ＨＴＴＰコネクションがＷｅｂＳｏｃｋｅｔコネクションに置き換えられた（もしくはアップグレードされた）後ではじめて、ＷｅｂＲＴＣＳｉｇハンドシェークを実施してもよく、このような置き換えは、好ましくは付加的な数バイトしか含まない独自のプロトコルによって実行され、そのようなプロトコルは"Ｔｈｉｎ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ"もしくは"ＷｅｂＲＴＣＳｉｇ Ｏｖｅｒ ＷｅｂＳｏｃｋｅｔｓ"とも呼ばれる。アップグレード手順後にはじめてＷｅｂＲＴＣＳｉｇハンドシェークを実施する、最後に挙げた選択肢に対して、アップグレード手順の一部分としてＷｅｂＲＴＣＳｉｇハンドシェークを実施する、最初に挙げた選択肢によれば、時間的に１つのラウンドトリップが節約される、という利点が得られる。厳密な時点もしくはタイミングについて言えば、ＷｅｂＲＴＣＳｉｇハンドシェークはたとえば、ＲＴＣクライアントがＪａｖａＳｃｒｉｐｔ （ＪＳクライアント）をＲＴＣサーバからロードした後に行われる。

本来のＷｅｂＲＴＣＳｉｇ情報は、使用されるＲＴＣシグナリングプロトコルに従い、たとえば以下のシグナリングプロトコルのバリエーションを含むことができる。

１）ＷｅｂＲＴＣＳｉｇタイプ１＝ＳＩＰ ａｎｄ ＳＤＰ ｏｖｅｒ ＷｅｂＳｏｃｋｅｔｓ（ＷｅｂＳｏｃｋｅｔを介したＳＩＰおよびＳＤＰ）

２）ＷｅｂＲＴＣＳｉｇタイプ２＝ＸＭＰＰ ａｎｄ Ｊｉｎｇｌｅ ｏｖｅｒ ＷｅｂＳｏｃｋｅｔｓ（ＷｅｂＳｏｃｋｅｔを介したＸＭＰＰおよびＪｉｎｇｌｅ）

３）ＷｅｂＲＴＣＳｉｇタイプ３＝"Ｐｒｏｐｒｉｅｔａｒｙ ＷｅｂＳｏｃｋｅｔｓ Ｓｉｇｎａｌｌｉｎｇ ｗｉｔｈ ＳＤＰ Ｅｍｂｅｄｄｅｄ （Ｏｆｆｓｅｔ）"（「ＳＤＰ埋め込み型の（オフセットを有する）プロプライエタリＷｅｂＳｏｃｋｅｔシグナリング」）
すなわち、ＳＤＰプロトコルメッセージを含むＷＳシグナリングメッセージ（ＷＳ ＝ ＷｅｂＳｏｃｋｅｔ）（たとえばＳＤＰ ＯｆｆｅｒによるＷＳセットアップ；ＳＤＰ ＡｎｓｗｅｒによるＷＳ Ｃｏｎｎｅｃｔ）。ファイアウォールがＳＤＰ Ｏｆｆｅｒ／Ａｎｓｗｅｒメッセージの開始を見つけられるように、ＳＤＰ Ｏｆｆｅｒメッセージの始点をアドレッシングするオフセット値を付加することができる／付加しなければならない。ここで述べておきたいのは、以下の２つの理由からＳＤＰがセッションシグナリングとして提供される、ということである。すなわち、
ａ）ＷｅｂＲＴＣブラウザＡＰＩ（Ｗ３Ｃ ＝ Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍで標準化されている）バージョン１は、ＳＤＰベースである。
ｂ）ＳＤＰは、ＳＩＰにおいてもセッション記述プロトコルである。
ＲＦＣ３２６４においてＯｆｆｅｒ／Ａｎｓｗｅｒモデルが例示的な標準化メッセージ要素として挙げられており、これには"ｍ＝ｖｉｄｅｏ ５３０００ ＲＴＰ／ＡＶＰ ３２"という行が含まれていて、その意味は、ポート５３０００を介してビデオを伝送せよ、ということである。

このことからＳＤＰによって、ＳＩＰワールドとの共働が簡単になる一方、セッションシグナリングとＷｅｂＲＴＣ−ＡＰＩとのクライアント側の共働が簡単になる。

メーカーがプロプライエタリなシグナリングプロトコルを用いるときに、それにもかかわらずメーカーは、かなりの確率でＳＤＰをプロプライエタリなメッセージと共に使用する。その理由は、ＷｅｂＲＴＣ−ＡＰＩも同様にＳＤＰを使用するからである。本発明によるＷｅｂＲＴＣＳｉｇタイプ３であるとしたならば、ＡＬＧファイアウォールはｂｙｔｅ ７７のところでスタートすべきであること、および（やはり標準化されているという理由から）ＳＤＰプロトコルとして解釈すべきであることが、付加情報として共にシグナリングされる。その前に存在するすべてのものは、つまりｂｙｔｅ ７６まではこのバイトも含めて、「プロプライエタリなセットアップメッセージ」の一部分である。

別の選択肢として、ブラウザはＷｅｂＲＴＣ−ＡＰＩのＳＤＰを、他のものにマッピングしてもよく、たとえばＨ．２４５、Ｊｉｎｇｌｅまたはプロプライエタリなフォーマットにマッピングしてもよく、これをＲＴＣシグナリングのために用いることができる。この場合には、これを異なるＷｅｂＲＴＣＳｉｇタイプによって表すことができる。このバリエーションは、シグナリングプロトコルをシグナリングメッセージと共に用いる、本発明による方法の１つの有利な実施形態に対応するものであり、このシグナリングメッセージによれば、オフセットが埋め込まれたセッション記述プロトコルのＯｆｆｅｒメッセージが用いられ、この場合、オフセットによってこのメッセージの始点がアドレッシングされる。

４）ＷｅｂＲＴＣＳｉｇタイプ４＝明示的なＳＤＰプロトコル
この場合であれば、ＷｅｂＲＴＣのためにＳＤＰプロトコルを明示的に標準化することができる。

５）ＷｅｂＲＴＣＳｉｇタイプ５＝本発明による予め定義されて伝達されたシンタックスにより取り決められたポート

６）ＷｅｂＲＴＣＳｉｇタイプ６＝ＲＥＳＴｆｕｌスタイル（ＲＥＳＴ ＝ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）で取り決められたポート：ポートを含む（サブ）構造が定義された既知のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）

７）ＷｅｂＲＴＣＳｉｇタイプ７＝ＲＥＳＴｆｕｌスタイルで取り決められたポート：ポートを受け取るべきリソース（サーバ）を指すポインタを含む既知のＵＲＩ

最後に挙げた２つのバリエーションは、やはり本発明による方法の１つの有利な実施形態に対応し、これによればＲＴＣシグナリングメッセージにおいて、取り決められたポートがＲＥＳＴｆｕｌスタイルで定義される。

８）ＷｅｂＲＴＣＳｉｇタイプ８＝シグナリングメッセージ内のＳＤＰのスタートを表すテキスト文字列がパラメータとして挿入される。この種の文字列は任意のものであり、メッセージの他の部分に再度出現しないものであればよい。

本発明が基礎とする課題はさらに、少なくとも１つのＲＴＣクライアントと、少なくとも１つのＲＴＣサーバと、複数のポートを備えた少なくとも１つのファイアウォールとを含む通信装置によって解決される。本発明によればファイアウォールは、これまで説明してきた方法を実施できるように構成された制御装置を備えている。

さらに、これまで説明してきた方法を実施するためのコンピュータプログラム製品、ならびにこの種のコンピュータプログラム製品が記憶されている機械読み取り可能なデータ媒体も、本発明に属するものとみなされる。

ＩＥＴＦは、現時点での理解によれば、たとえばＳＩＰまたはＨ．３２３について実施したような、完全なＷｅｂＲＴＣシグナリングプロトコルの標準化を行わないと思われる。したがってＡＬＧファイアウォールは、本来のＲＴＰパケットが送信される取り決められたＵＤＰポートを見つけ出す目的で、あらゆる環境で動的にシグナリングプロトコルを理解しなければならない場合には、ＷｅｂＲＴＣアプリケーションのすべてのメーカーのＷｅｂＲＴＣシグナリングプロトコルを実装しなければならない。このことは、選択されたシグナリングプロトコルを複数のカテゴリに分類することによって（つまりたとえば任意にナンバリングすることで）、回避することができる。ＡＬＧファイアウォールが、ＷｅｂＲＴＣシグナリングタイプ１であることを検出もしくは読み取ったならば、そのファイアウォールは、ＳＩＰ／ＳＤＰに従って構文解析しなければならない、ということを理解する。これに対しＡＬＧファイアウォールが、ＷｅｂＲＴＣシグナリングタイプ３がオフセット７７と共に用いられる、ということを読み取ったならば、ＡＬＧファイアウォールは、そのメッセージをｂｙｔｅ ７７からＳＤＰプロトコルとして構文解析しなければならないことを把握する、といった具合に行われる。ＷｅｂＲＴＣシグナリングタイプ４であれば、ｂｙｔｅ １からＳＤＰプロトコルである。さらにＷｅｂＲＴＣシグナリングタイプ５に、明示的なソースおよび宛先のＵＤＰポートの記述が加えられていれば、ＡＬＧファイアウォールに正確にＵＤＰポートが伝達され、この場合にはＳＤＰプロトコルは用いられない。

本発明のその他の利点、特徴および独自性は、図面を参照しながら有利な実施形態について以下で説明していくことで明らかになる。

本発明による通信装置の１つの実施形態に関する概略図。 本発明によるファイアウォールトラバース方法の実施形態について略示した流れ図。 本発明によるファイアウォールトラバース方法の実施形態について略示した流れ図。 本発明によるファイアウォールトラバース方法の実施形態について略示した流れ図。 すでに知られているファイアウォールトラバース方法について略示した流れ図。

図１に示した本発明による通信装置１０には、ＲＴＣクライアント２０、ＲＴＣサーバ３０およびファイアウォール４０が含まれている。一方の側におけるクライアント２０を伴うファイアウォール４０と、他方の側におけるサーバ３０とのメッセージ交換が、いくつかの少数の矢印によってシンボリックに表されている。さらにこの図には、ファイアウォール４０が複数のポートを備えていることも示されており、それらのポートは参照符号Ｐ１， Ｐ２， Ｐ３を用いてごく概略的に表されている。ファイアウォール４０には、制御装置４２たとえばＣＰＵまたはプロセッサ群が含まれており、これによってファイアウォール４０の機能が実現される。さらにこの図には、データ媒体の一例としてＣＤ−ＲＯＭ９０が示されており、そこにコンピュータプログラムもしくはコンピュータプログラム製品９２が記憶されていて、本発明による方法を実現する目的で、相応のコンピュータプログラム９２を含むデータ媒体９０が制御装置４２に提供される。

図２には、本発明によるファイアウォールトラバース方法の第１の実施形態が示されており、この実施形態によれば、上述の説明によるＲＴＣシグナリングタイプ３が実現される。最初にブラウザ２２は、メッセージＮ０１「ＨＴＴＰリクエスト」をＷｅｂサーバ３２に送信し、Ｗｅｂサーバ３２は（ＪａｖａＳｃｒｉｐｔ／ＨＴＭＬ５用の）ファンクションユニット２４へのメッセージＮ０２「ＨＴＴＰレスポンス」によって、メッセージＮ０１に対して応答し、これによってＨＴＴＰコネクションが確立される。その後、ファンクションユニット２４は、ＷｅｂＳｏｃｋｅｔアップグレード手順の過程で、相応のメッセージＮ１１をＷｅｂサーバ３２内のＷｅｂＳｏｃｋｅｔサーバ３４へ送信し、この場合、メッセージＮ１１には、ＷｅｂＲＴＣシグナリングタイプとＳＤＰ＿Ｏｆｆｓｅｔマーカが含まれている。ＷｅｂＳｏｃｋｅｔサーバ３４は、ＷｅｂＲＴＣクライアント２０に対し、メッセージＮ１２によってアップグレード手順を確認する。最後にＷｅｂＲＴＣクライアント２０は、ＷｅｂＲＴＣサーバにメッセージＮ１３を送信し、このメッセージには、シグナリングメッセージが２５５のＳＤＰ＿Ｏｆｆｓｅｔでスタートする、という情報が含まれている。このようにしてファイアウォール４０は、ＳＤＰをｂｙｔｅ ２５５のところで見つける。ＷｅｂＲＴＣサーバ３０からＷｅｂＲＴＣクライアント２０への相応のメッセージＮ１４（サーバとクライアントの双方はＯｆｆｅｒ／Ａｎｓｗｅｒプロトコルを使用）により、シグナリングがＳＤＰ＿Ｏｆｆｓｅｔマーキングによって終了する。このような形式のシグナリングによって、ファイアウォール４０は、自身にとって重要な情報がどこにあるのか（ここではｂｙｔｅ ２５５以降）を「読み取る」ことができる。この情報は、新たなヘッダフィールド内で伝達され、そこには、情報欄１１内に「ブラウザリクエスト」という見出しの下に最終行として書き込まれているように、タイプとＳＤＰ＿Ｏｆｆｓｅｔが記述されている。情報欄１１内において「Ｗｅｂサーバレスポンス」という見出しの下の最終行に示されているように、ＷｅｂＲＴＣサーバ３０はＷｅｂＲＴＣクライアント２０に対し、取り決められたシグナリングタイプはＮｏ．３であることを確認して、"ＯＫ"と共に、取り決められたＳＤＰ＿Ｏｆｆｓｅｔマーキングによってシグナリングが行われる、ということを知らせる。

図２に示されているその他の事項は、この技術分野における一般的な事項に相応するものであり、したがって別途説明する必要はない。

シグナリングが首尾よく完了した後、ファイアウォール４０を通り抜けてメディアデータを伝送することができ、そのために他のプロトコルたとえばＲＴＰ （Ｒｅａｌｔｉｍｅ Ｐｒｏｔｏｃｏｌ）、ＳＴＵＮ （Ｓｅｓｓｉｏｎ Ｔｒａｖｅｒｓａｌ Ｕｔｉｌｉｔｉｅｓ ｆｏｒ ＮＡＴ， ＮＡＴ ＝ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）， ＩＣＥ （Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）などが用いられる。

既述のように、本発明によればＷｅｂＲＴＣシグナリングのタイプが伝達され（この実施例では任意に与えられたＮｏ．３のタイプ）、ＳＤＰ＿Ｏｆｆｓｅｔという記号がある個所に、シグナリングメッセージ内のＳＤＰを指すポインタを表すテキスト文字列が存在する。この種の文字列は任意のものであり、メッセージの他の部分に再度出現しないものであればよい。この実施例で挙げた"ＳＤＰ＿Ｏｆｆｓｅｔ"という記号の代わりに、たとえば十分な長さのランダムなキャラクタシーケンスであっても、上述の要求を満たすことができる。

図３に示した本発明による方法の第２の実施形態が第１の実施形態と相違する点は、メッセージＮ２１およびＮ２２を用いたＷｅｂＳｏｃｋｅｔコネクションへのアップグレード手順において、異なるシグナリングタイプ（この実施例では５）とファイアウォール４０が開放すべきポート値とが伝送されることである。換言すれば、シグナリングメッセージＮ２３には、この実施例では"Ｏｐｅｎ＿Ｐｏｒｔｓ： ６２２５５， ６２２５６， ３１２３４， ３１２３５"で表された構成要素が含まれており、確認メッセージＮ２４がこれに続く。これに応じて、ファイアウォール４０は対応するポートを開放する。したがって新たなヘッダフィールドには、シグナリングタイプＮｏ．５と"Ｏｐｅｎ＿Ｐｏｒｔｓ"の記述がエントリされる。最後の個所には、シグナリングメッセージにおけるメディアのためのＲＴＰポートを表すテキスト文字列が存在する。この文字列は任意のものであるが、メッセージの他の部分に再度出現しないものであるのが望ましい。情報欄１２内において「ブラウザリクエスト」の見出しの下の最終行に記載された具体例である"Ｏｐｅｎ＿Ｐｏｒｔｓ"の代わりに、たとえば十分な長さのランダムなキャラクタシーケンスであっても、上述の要求を満たすことができる。同様に、ＷｅｂＲＴＣクライアント２０に対するＷｅｂＲＴＣサーバ３０のレスポンスには、取り決められたＮｏ．５のシグナリングタイプの確認、およびポートが開放されたという（オプションとしての）確認が含まれている（情報欄１２も参照されたい）。このようにして、ポート値を用いたシグナリングが実行される。

図４に示した本発明による方法の第３の実施形態が、これまで述べてきた２つの実施形態と相違する点は、メッセージＮ３１およびＮ３２を用いたＷｅｂＳｏｃｋｅｔコネクションへのアップグレード手順において、異なるＷｅｂＲＴＣシグナリングタイプつまりＮｏ．８と、シグナリングメッセージＮ３３およびＮ３４におけるＳＤＰのスタートを表すテキスト文字列とが伝達されることである。したがってファイアウォール４０は、ＳＤＰが埋め込まれた未知のプロトコルが用いられることを識別し、テキスト文字列"Ｈｅｒｅ＿ｓｔａｒｔｓ＿ＳＤＰ"を探索し、ＳＤＰ内に含まれていたＲＴＰポートを開放する。その結果、新たに導入されたヘッダフィールドには、シグナリングタイプとしてＮｏ．８が挙げられており、情報欄１３に示されているように「ブラウザリクエスト」内にテキスト文字列"Ｈｅｒｅ＿ｓｔａｒｔｓ＿ＳＤＰ"が含まれている。したがってＷｅｂＲＴＣクライアント２０に対するＷｅｂＲＴＣサーバ３０の相応のレスポンス（メッセージＮ３４内）にも、取り決められたシグナリングタイプ８と、ＳＤＰ＿Ｓｔａｒｔ文字列によりシグナリングが実施されるという確認とが含まれている。たとえばここで挙げたテキスト文字列"Ｈｅｒｅ＿ｓｔａｒｔｓ＿ＳＤＰ"の代わりに、十分な長さの他のランダムなキャラクタシーケンスであっても、それがメッセージの残りの部分で再度出現しないかぎり、使用することができる。

ここで確認しておくと、たとえば使用されるクライアント、サーバ、コネクションおよびプロトコルの種類や形態など、図示されている実施形態を参照しながら説明してきた本発明の特徴は、それらとは異なるように記載されていたり、または技術的な理由から当然禁止される場合を除いて、さらに別の実施形態において設けることもできる。また、組み合わせとして説明した個々の実施形態の上述のような特徴のうち、該当する１つの実施形態の特徴すべてが常に必ずしも実現されなくてもよい。

１０ 通信装置
１１〜１４ 情報欄
２０ （Ｗｅｂ）ＲＴＣクライアント
２２ ブラウザ
２４ ファンクションユニット
３０ （Ｗｅｂ）ＲＴＣサーバ
３２ Ｗｅｂサーバ
３４ ＷｅｂＳｏｃｋｅｔサーバ
４０ ファイアウォール
４２ 制御装置
９０ データ媒体
９２ コンピュータプログラム製品
Ｎ０１〜Ｎ９４ メッセージ
Ｐ１〜Ｐ３ ポート

Claims (7)

1. 標準化されていないＲＴＣシグナリングプロトコルを用いて、ＲＴＣクライアント（２０）とＲＴＣサーバ（３０）との間でＲＴＣ通信コネクションを確立するときに、前記標準化されていないＲＴＣシグナリングプロトコルの情報を有していないアプリケーションレイヤ・ゲートウェイ・ファイアウォール（４０）をトラバースするための方法であって、
   ・前記ＲＴＣクライアント（２０）と前記ＲＴＣサーバ（３０）とが、前記ＲＴＣ通信コネクションを確立するときに、前記ファイアウォール（４０）のいずれのポート（Ｐ１， Ｐ２， Ｐ３）を、前記ＲＴＣ通信コネクションを介して交換すべきデータパケットのために必要とするのかを取り決めるステップであって、当該取り決めにおいて、前記ＲＴＣクライアント（２０）と前記ＲＴＣサーバ（３０）とは、前記標準化されていないＲＴＣシグナリングプロトコルの構成部分として、使用すべきポートに関する情報を見つけ出すことのできる少なくとも１つの標準化されたメッセージ要素を使用する、ステップと、
   ・前記ＲＴＣ通信コネクションを確立するときに、前記ファイアウォール（４０）は、前記標準化されたメッセージ要素を用いて、前記ファイアウォール（４０）のいずれのポート（Ｐ１， Ｐ２， Ｐ３）が、前記ＲＴＣ通信コネクションを介して交換すべきデータパケットのために前記ＲＴＣクライアント（２０）と前記ＲＴＣサーバ（３０）とにより必要とされると取り決められたのかを検出するステップと、
   ・前記ファイアウォール（４０）が、必要とされる前記ポート（Ｐ１， Ｐ２， Ｐ３）を、前記取り決めの結果に従い動的に開放および閉鎖するステップと、
   を含み、
   必要とされる前記ポート（Ｐ１， Ｐ２， Ｐ３）の取り決めのために、定義されたシグナリングプロトコルバリエーションを用い、当該シグナリングプロトコルバリエーションを、前記ＲＴＣクライアント（２０）と前記ＲＴＣサーバ（３０）との間のシグナリング伝送コネクションの確立後、ＲＴＣシグナリングを介して交換する、
   アプリケーションレイヤ・ゲートウェイ・ファイアウォール（４０）をトラバースするための方法。
2. 前記シグナリングプロトコルバリエーションの交換を、ＨＴＴＰコネクションからＷｅｂＳｏｃｋｅｔコネクションへのアップグレード手順の一部分として行う、
   請求項１に記載の方法。
3. 前記シグナリングプロトコルバリエーションの交換のために、ＷｅｂＳｏｃｋｅｔプロトコルにおける拡張を使用し、特にヘッダ内に定義された１つのフィールドを使用する、
   請求項２に記載の方法。
4. 前記シグナリングプロトコルバリエーションの交換を、独自のプロトコルを使用してＨＴＴＰコネクションからＷｅｂＳｏｃｋｅｔコネクションへのアップグレード手順を実施した後にはじめて行う、
   請求項１に記載の方法。
5. 請求項１から４までのいずれか１項に記載の方法を実施するためのコンピュータプログラム（９２）。
6. 請求項５に記載のコンピュータプログラム（９２）が記憶されている、機械読み取り可能なデータ媒体（９０）。
7. 標準化されていないＲＴＣシグナリングプロトコルを用いて、ＲＴＣクライアント（２０）とＲＴＣサーバ（３０）との間でＲＴＣ通信コネクションを確立するときに、前記標準化されていないＲＴＣシグナリングプロトコルの情報を有していないアプリケーションレイヤ・ゲートウェイ・ファイアウォール（４０）のトラバースを実現可能な通信システム（１０）であって、
   ・ＲＴＣクライアント（２０）と、
   ・ＲＴＣサーバ（３０）と、
   ・複数のポート（Ｐ１， Ｐ２， Ｐ３）を備えたファイアウォール（４０）と
   を備え、
   前記ファイアウォール（４０）は、請求項１から４までのいずれか１項に記載の方法を実施するための制御装置（４２）を有することを特徴とする、
   通信システム（１０）。

Images