(57)【要約】      （修正有）【課題】ブラウザベースのＡＬＭを実装する際に、新規ノードが近隣ノードを選択して、従来よりも速くネットワークに接続する方法、システム及びプログラムを提供する。【解決手段】接続要求を受信した接続サーバーは、既接続通信装置から新規接続通信装置の複数の接続候補を選択し、既接続装置に接続候補選択通知を送信する。既接続通信装置は、提案情報と通信経路候補情報を接続サーバーに送信する。接続サーバーは、複数の既接続通信装置の提案情報に含まれる共通情報を抽出し、通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として共通情報と共に、新規接続通信装置に送信する。新規接続通信装置は、回答情報と通信経路情報を接続サーバーに送信する。接続サーバーは、受信した回答情報と通信経路候補情報を複数の既接続通信装置に送信する。【選択図】図１
2019145916.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する通信装置接続方法であって、
前記ネットワークに新規に接続する新規接続通信装置は、接続サーバーに接続要求を送信し、
前記接続要求を受信した前記接続サーバーが、前記ネットワークを構成する既接続通信装置から前記新規接続通信装置の複数の接続候補を選択し、前記既接続装置に接続候補選択通知を送信し、
前記接続候補選択通知を受信した前記複数の既接続通信装置は、提案情報と通信経路候補情報を前記接続サーバーに送信し、
前記提案情報と前記通信経路候補情報を受信した前記接続サーバーは、前記複数の既接続通信装置の前記提案情報に含まれる共通情報を抽出し、前記通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として前記共通情報と共に、前記新規接続通信装置に送信し、
前記共通情報とネットワークインタフェース情報を受信した前記新規接続通信装置は、回答情報と通信経路情報を前記接続サーバーに送信し、
前記接続サーバーは、受信した前記回答情報と通信経路候補情報を前記複数の既接続通信装置に送信する
ことを特徴とする通信装置接続方法。
【請求項２】
アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する通信装置接続システムであって、
前記ネットワークに新規に接続する新規接続通信装置は、接続サーバーに接続要求を送信し、
前記接続要求を受信した前記接続サーバーが、前記ネットワークを構成する既接続通信装置から前記新規接続通信装置の複数の接続候補を選択し、前記既接続装置に接続候補選択通知を送信し、
前記接続候補選択通知を受信した前記複数の既接続通信装置は、提案情報と通信経路候補情報を前記接続サーバーに送信し、
前記提案情報と前記通信経路候補情報を受信した前記接続サーバーは、前記複数の既接続通信装置の前記提案情報に含まれる共通情報を抽出し、前記通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として前記共通情報と共に、前記新規接続通信装置に送信し、
前記共通情報とネットワークインタフェース情報を受信した前記新規接続通信装置は、回答情報と通信経路情報を前記接続サーバーに送信し、
前記接続サーバーは、受信した前記回答情報と通信経路候補情報を前記複数の既接続通信装置に送信する
ことを特徴とする通信装置接続システム。
【請求項３】
アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する通信装置接続プログラムであって、
コンピュータに、
接続サーバーに接続要求を送信し、
前記接続サーバーが前記ネットワークを構成する既接続通信装置から選択した、複数の接続候補の各既接続装置の提案情報に含まれる共通情報と共に、前記複数の接続候補の各既接続装置の通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報とを、上記接続サーバーから受信し、
回答情報と通信経路情報を前記接続サーバーに送信する
ことを実行させることを特徴とする通信装置接続プログラム。
【請求項４】
アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する接続サーバーの通信装置接続プログラムであって、
コンピュータに、
前記ネットワークに新規に接続する新規接続通信装置から接続要求を受信すると、前記ネットワークを構成する既接続通信装置から前記新規接続通信装置の複数の接続候補を選択し、前記既接続装置に接続候補選択通知を送信し、
前記複数の接続候補とする前記既接続装置から提案情報と通信経路候補情報を受信すると、前記既接続通信装置の前記提案情報に含まれる共通情報を抽出し、前記通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として前記共通情報と共に、前記新規接続通信装置に送信し、
前記共通情報とネットワークインタフェース情報を受信した前記新規接続通信装置から、回答情報と通信経路情報を受信した前記回答情報と通信経路候補情報を前記複数の既接続通信装置に送信する
ことを実行させることを特徴とする通信装置接続プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置接続方法、通信装置接続システム及び通信装置接続プログラムに関する。
【背景技術】
【０００２】
複数の端末にデータを配信するための方法として、ＩＰマルチキャスト技術やアプリケーションレイヤーマルチキャスト技術（以下「ＡＬＭ」、又は、「オーバーレイネットワーク」と呼ぶ。）は手法としては広く知られている。これらは配信元端末（もしくはサーバー）の負荷を低減しつつ複数の配信先端末に配信する方法である。これらの技術は、一般にはデータの種類として映像音声を含む多種多様なものをサポートすることができ、またリアルタイムのライブ配信にも蓄積型の配信にも対応することが可能である。なお、ここでは、映像音声のようなマルチメディアストリームをライブ配信する場合に限定して議論することとする。
【０００３】
ＩＰマルチキャスト技術は、ＩＰ層において配信データの経路制御や複製処理を行う手法である。ＩＰマルチキャスト技術では、配信経路上のルーターがデータの複製処理を行うので、配信先端末が増えても、配信元端末の負荷が増大しない。プロトコルとしては、ＩＰｖ４ではＩＧＭＰ，ＩＰｖ６ではＭＤＬｖ２と呼ばれるものが使われる。欠点としては、配信元端末から配信先端末までの経路上のルーターがすべてこれらの特別なプロトコルを処理できる必要が有ることである。ＩＰマルチキャストを可能にするインフラストラクチャはまだ普及しているとは言えず、特に企業内ネットワークでは普及していない。
【０００４】
ＡＬＭ技術は、ＩＰマルチキャストと同様に、経路上の装置がデータを複製することによって配信元端末の負荷増大を抑え、配信先の端末数の増大に対処する手法である。ＡＬＭ技術とＩＰマルチキャスト技術との違いは、データ複製を配信先端末が行う点である。
【０００５】
ＡＬＭ技術における共通課題の１つとして、ＡＬＭでのノード間の隣接関係が、下層のトランスポートネットワークにおける距離（ルーターホップ数など）を反映するようにすることがある。そのため、どのようにＡＬＭを構築するか、あるいは新規参加のノードが既存のどのノードに接続するかに関して、特許文献１や特許文献２等に開示される幾つかの手法が存在する。
【０００６】
さて、最近、映像を撮影する手段として、ＰＣに接続されたＵＳＢカメラやスマートフォン内蔵カメラのような手軽なものが普及しており、またそれに伴ってリアルタイムで撮像した映像を複数の端末（場合によっては不特定多数の端末）に配信したいというニーズも高まっている。
【０００７】
映像を含んだメディアストリームはデータ量が大きいため、同一のストリームを複数個所でリアルタイムに視聴した場合には、特に無駄が生じやすい。上述のＡＬＭによる配信は複数の端末に対する映像等のメディアストリームをリアルタイム配信する方法として利用可能である。
【０００８】
ＷｅｂＲＴＣを使ったメディアストリームのリレーをＡＬＭ構築の際の基礎として利用することは可能である。ＡＬＭ専用端末（ハードウェアあるいはソフトウェア）における端末配布（デプロイ、インストール）にかかる手間・コストを削減できる点でも望ましい。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００９−１３０６６７号公報
【特許文献２】特開２００５−９４７７３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、ＡＬＭ専用端末を前提にした上流ノード・隣接ノードの探索については、特許文献１や特許文献２に開示される手法が存在するが、これらの手法は、ＡＬＭでＷｅｂアプリケーションを構築する際には必ずしもそのままの形で利用できるものではないという課題がある。
【００１１】
ＡＬＭ専用端末ソフトウェアを利用する場合は、ソフトウェアコードでネットワークプログラミングを（ソケットをバインドするところから）全部コーディングしているので、これらの手法を利用するためのプログラミングが可能である。
【００１２】
それに対して、ＷｅｂＲＴＣはＷｅｂブラウザで動作するものであり、Ｗｅｂブラウザはセキュリティの問題も有り、できることが限定されており、ＡＬＭ用の特別なソフトウェアで実施可能な手法も使用できないことが多い。
【００１３】
特に、新規ノードがＡＬＭに参加する際に、ＡＬＭ内の近隣のノードを探索する問題は、Ｗｅｂアプリケーションとして実装可能なものの範囲では解決が難しい。
【００１４】
例えば、対象ノードとのネットワーク的な距離をパケット到達のｒｏｕｎｄ−ｔｒｉｐｔｉｍｅで測定しても、それに必要なネットワークプログラミングはＷｅｂブラウザ内で動くアプリケーション（例えばＪａｖａＳｃｒｉｐｔ（登録商標）でコーディングされるものを指しており、以下では、単にＷｅｂアプリケーションと呼ぶ。）では行えない。
【００１５】
また、ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトのｇｅｔＳｔａｔｓメソッドで、そのような情報が取得可能であるかもしれないが、それが呼び出せるようになるのはすでにＷｅｂＲＴＣで相手と接続した後、つまりＷｅｂＲＴＣベースのＡＬＭであれば、ＡＬＭにすでに参加した状態の場合となる。したがって、ＡＬＭにノードが参加する前に、どのノードを上流ノードとしてＡＬＭに参加するかという問題を解決するものではない。
【００１６】
以上のように、Ｗｅｂアプリケーションメディアリレーを行うことでＡＬＭを実現する場合、従来のＡＬＭ技術で利用されていたネットワーク構築手法あるいは近隣ノード探索手法がそのままの形では利用可能ではないという問題点があった。
【００１７】
そのため、本発明は、ブラウザベースのＡＬＭを実装する際に新規参加ノードが近隣ノードを選択して、従来よりも速くネットワークに接続することができる通信装置接続方法、通信装置接続システム及び通信装置接続プログラムを提供しようとするものである。
【課題を解決するための手段】
【００１８】
上記のような課題を解決するために、第１の本発明に係る通信装置接続方法は、アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する通信装置接続方法であって、（１）ネットワークに新規に接続する新規接続通信装置は、接続サーバーに接続要求を送信し、（２）接続要求を受信した接続サーバーが、ネットワークを構成する既接続通信装置から新規接続通信装置の複数の接続候補を選択し、既接続装置に接続候補選択通知を送信し、（３）接続候補選択通知を受信した複数の既接続通信装置は、提案情報と通信経路候補情報を前記接続サーバーに送信し、（４）提案情報と通信経路候補情報を受信した接続サーバーは、複数の既接続通信装置の提案情報に含まれる共通情報を抽出し、通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として共通情報と共に、新規接続通信装置に送信し、（５）共通情報とネットワークインタフェース情報を受信した新規接続通信装置は、回答情報と通信経路情報を接続サーバーに送信し、（６）接続サーバーは、受信した回答情報と通信経路候補情報を複数の既接続通信装置に送信することを特徴とする通信装置接続方法である。
【００１９】
第２の本発明に係る通信装置接続システムは、アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する通信装置接続システムであって、（１）ネットワークに新規に接続する新規接続通信装置は、接続サーバーに接続要求を送信し、（２）接続要求を受信した接続サーバーが、ネットワークを構成する既接続通信装置から新規接続通信装置の複数の接続候補を選択し、既接続装置に接続候補選択通知を送信し、（３）接続候補選択通知を受信した複数の既接続通信装置は、提案情報と通信経路候補情報を接続サーバーに送信し、（４）提案情報と通信経路候補情報を受信した接続サーバーは、複数の既接続通信装置の提案情報に含まれる共通情報を抽出し、通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として共通情報と共に、新規接続通信装置に送信し、（５）共通情報とネットワークインタフェース情報を受信した新規接続通信装置は、回答情報と通信経路情報を接続サーバーに送信し、（６）接続サーバーは、受信した回答情報と通信経路候補情報を複数の既接続通信装置に送信することを特徴とする通信装置接続システムである。
【００２０】
第３の本発明に係る通信装置接続プログラムは、アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する通信装置接続プログラムであって、コンピュータに、（１）接続サーバーに接続要求を送信し、（２）接続サーバーがネットワークを構成する既接続通信装置から選択した、複数の接続候補の各既接続装置の提案情報に含まれる共通情報と共に、複数の接続候補の各既接続装置の通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報とを、接続サーバーから受信し、（３）回答情報と通信経路情報を接続サーバーに送信することを実行させることを特徴とする通信装置接続プログラムである。
【００２１】
第４の本発明に係る通信装置接続プログラムは、アプリケーション層マルチキャスト通信が行われるツリー状のネットワークに通信装置を接続する接続サーバーの通信装置接続プログラムであって、コンピュータに、（１）ネットワークに新規に接続する新規接続通信装置から接続要求を受信すると、ネットワークを構成する既接続通信装置から新規接続通信装置の複数の接続候補を選択し、既接続装置に接続候補選択通知を送信し、（２）複数の接続候補とする既接続装置から提案情報と通信経路候補情報を受信すると、既接続通信装置の提案情報に含まれる共通情報を抽出し、通信経路候補情報を１つの接続候補の複数のネットワークインタフェース情報として共通情報と共に、新規接続通信装置に送信し、（３）共通情報とネットワークインタフェース情報を受信した新規接続通信装置から、回答情報と通信経路情報を受信した回答情報と通信経路候補情報を複数の既接続通信装置に送信することを実行させることを特徴とする通信装置接続プログラムである。
【発明の効果】
【００２２】
本発明によれば、ブラウザベースのＡＬＭを実装する際に新規参加ノードが近隣ノードを選択して、従来よりも速くネットワークに接続することができる。
【図面の簡単な説明】
【００２３】
【図１】実施形態に係る通信装置接続処理を示すシーケンス図である（その１）。
【図２】実施形態に係る通信装置接続処理を示すシーケンス図である（その２）。
【図３】実施形態に係る通信装置接続システムの全体構成を示す図である。
【図４】ＡＬＭでの配信ネットワークの構成を示す図である。
【図５】ＡＬＭでのルーターを含む配信ネットワーク構成を示す図である。
【図６】１台の配信元端末が複数の配信先端末に配信する配信ネットワークの構成を示す図である。
【図７】中継サーバーを介して配信先端末に配信する配信ネットワークの構成を示す図である。
【図８】配信先端末の上で動いているＡＬＭ制御ソフトウェアの機能構成を示すブロック図である。
【図９】ＮＡＴ装置を介して発呼ノードと着呼ノードの接続構成を説明する説明図である（その１）。
【図１０】ＮＡＴ装置を介して発呼ノードと着呼ノードの接続構成を説明する説明図である（その２）。
【図１１】ＮＡＴ装置を介して発呼ノードと着呼ノードの接続構成を説明する説明図である（その３）。
【図１２】ＮＡＴ装置を介して発呼ノードと着呼ノードの接続構成を説明する説明図である（その４）。
【図１３】Ｔｒｉｃｋｌｅ  ＩＣＥの手順を示すシーケンス図である（その１）。
【図１４】Ｔｒｉｃｋｌｅ  ＩＣＥの手順を示すシーケンス図である（その２）。
【発明を実施するための形態】
【００２４】
以下では、図４〜図１４を参照して、本発明に関連する関連技術を説明した上で、図１〜図３を参照して本発明に係る実施形態を詳細に説明する。
【００２５】
［アプリケーションレイヤーマルチキャスト（ＡＬＭ）による映像配信］
上述したように、ＡＬＭは、ＩＰマルチキャストと同様に、経路上の装置がデータを複製することによって配信元の負荷の増大を抑え、配信先の端末数の増大に対処する手法である。ＩＰマルチキャストとの違いは、データの複製を配信先端末がおこなう点であり、図４〜図７を参照して説明する。
【００２６】
図４において、１０１は配信元端末で、１０２〜１０７は配信先端末（ここでは配信元端末が中継端末を兼務しているものとする。）であるとする。また、各端末の間を結んでいる線は、データ伝送の経路であるとする。なお、この線は、物理的なネットワーク接続を示すものでない点に注意するべきである。
【００２７】
ここに登場する端末（配信元端末１０１、配信先端末１０２〜１０７）はいずれもＩＰ  ｒｅａｃｈａｂｌｅでありさえすればよく、例えばＩＰルーターを含んだネットワーク構造は、図４のようなものになっているかもしれない。例えば、図４では配信元端末１０１が木構造のルートにあるが、実際のネットワーク構成である図５では配信元端末１０１は特別な位置を占めるものではない。
【００２８】
図４において、配信先端末１０２は、配信元端末１０１からデータ配信を受けているが、受信したデータを複製したものを配信先端末１０３および配信先端末１０４に再配信（中継）している。同様に、配信先端末１０５も、データを複製して配信先端末１０６及び配信先端末１０７に中継している。なお、この例ではデータの配信経路は木構造になっているが、冗長性を確保するためにＤＡＧ（Ｄｉｒｅｃｔｅｄ  Ａｃｙｃｌｉｃ  Ｇｒａｐｈ）にする場合もある。以下では、説明を容易にするため、ＡＬＭでの配信ネットワーク構造は木構造だけを考える。
【００２９】
いずれにしても、図４に示すように、配信先端末１０２が下流側に存在する配信先端末１０３及び１０４に対して複製したデータを再配信することができる。このようにして、配信元端末１０１に配信負荷が集中することを防ぐことができる。ＡＬＭを使わなければ、例えば、図６に例示するように、配信元端末１０１が、全ての配信先端末１０２〜１０７に直接配信することになり、配信先端末の数が増えてくると、これは非現実的である。
【００３０】
あるいは、図７のように特別な中継サーバー１１１を立てる方法も有る。この方法では、配信元端末１０１が中継サーバー１１１だけに映像を配信し、各配信先端末１０２〜１０７は、中継サーバー１１１から映像を受信する。この形態は実際に機能し、現実に広く利用されているが、中継サーバー１１１にネットワーク負荷ならびにＣＰＵ負荷が集中することになる。そのため、サーバーハードウェアあるいはネットワークインフラ等に投資する必要が有るという問題がある。上記のことから、図４に示すようなＡＬＭの方式も適用分野によっては依然として有用であると考えられる。
【００３１】
ＡＬＭ技術における共通課題として、ＡＬＭでのノード間の隣接関係が、下層のトランスポートネットワークにおける距離（ルーターホップ数など）を反映するようにすることがある。
【００３２】
例えば、ＡＬＭが図４、下層のトランスポートネットワークが図５のようなものになっていたとする。この場合、図４における配信先端末１０２およびその下流側にいる配信先端末１０３及び１０４は図５でルーター２０２の配下のネットワークに集中しており、図４における配信先端末１０５およびその下流側にいる配信先端末１０６及び１０７は図５でルーター２０３の配下のネットワークに集中しているので、ほぼ問題ない。例えば、図４で配信元端末１０１から配信先端末１０５を経由して配信先端末１０６に配信される映像は、図５では配信元端末１０１→ルーター２０２→ルーター２０１→ルーター２０３→配信先端末１０５→配信先端末１０６という経路を通ることになる。
【００３３】
そうではなくて、配信先端末１０６が図５でルーター２０２の下にあるとすると、図４で配信元端末１０１から配信先端末１０５を経由して配信先端末１０６に配信される映像は、図５では配信元端末１０１→ルーター２０２→ルーター２０１→ルーター２０３→配信先端末１０５→ルーター２０３→ルーター２０１→ルーター２０２→配信先端末１０６という経路を通ることになり、各ルーターを無駄にトラフィックが流れることになる。
【００３４】
［ＷｅｂＲＴＣ］
さて、近年、ＨＴＭＬ５等の最新仕様に対応したＷｅｂブラウザの普及に伴い、特別なソフトウェアをインストールしなくても、配信表示用のＷｅｂページをブラウザで表示するだけで映像を視聴できることが当たり前になってきている。
【００３５】
Ｗｅｂブラウザで（すなわち、プラグイン等のインストールなしで）映像を視聴できるようにする配信方式としては、例えば、ＨＴＴＰストリーミング（ＭＰＥＧ−ＤＡＳＨ（ＭＰＥＧ  Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）ならびにＨＬＳ（ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ））および、ＷｅｂＲＴＣ（Ｗｅｂ  Ｒｅａｌ−ｔｉｍｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）がある。これらの仕様は、Ｇｏｏｇｌｅ  Ｃｈｒｏｍｅ（登録商標）など市場で普及しているＷｅｂブラウザで利用可能である。
【００３６】
上記のような仕様の中で、ＷｅｂＲＴＣは、本来はブラウザ同士でビデオ通話を行うことを主要なユースケースと想定して作成された仕様であり、メディアの伝送がサーバーを介さずに端末（ブラウザ）間で直接実行されるという特徴を持っている。
【００３７】
通話のためのシグナリングプロトコルはＷｅｂＲＴＣ仕様では規定されないが、ブラウザ同士での能力交換をＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）同様のｏｆｆｅｒ−ａｎｓｗｅｒで行うモデルを採用している。
【００３８】
［ＷｅｂＲＴＣを使ったメディアストリームのリレーならびにＡＬＭ配信］
上述の通り、ＷｅｂＲＴＣはメディアの伝送がサーバーを介さずに端末間で直接実行されるという特徴を持っている。そのため、上述のようなリアルタイムメディア配信のためのＡＬＭは、ＷｅｂＲＴＣ技術を使って構築することができる。なお、ＷｅｂＲＴＣにおけるメディアストリームに関する技術は、参考文献１（Ｐｅｅｒ  ｃｏｎｎｅｃｔｉｏｎ  ｒｅｌａｙ，https://webrtc.github.io/samples/src/content/peerconnection/multiple-relay/）、参考文献２（Ｐｅｅｒ  ＣｏｎｎｅｃｔｉｏｎリレーとＭｅｄｉａＲｅｃｏｒｄｅｒ−ＳｌｉｄｅＳｈａｒｅ，https://www.slideshare.net/mganeko/peerconnectionmediarecorder），特にスライド５）、参考文献３（ＧｉｔＨｕｂ−ｍｇａｎｅｋｏ／ｗｅｂｒｔｃｅｘｐｊｐ：ＷｅｂＲＴＣ  Ｅｘｐｅｒｉｍｅｎｔｓ  Ｊａｐａｎ／ＷｅｂＲＴＣ実験室，https://github.com/mganeko/webrtcexpjp#%E6%89%8B%E5%8B%95%E3%82%B7%E3%82%B0%E3%83%8A%E3%83%AA%E3%83%B3%E3%82%B0%E7%95%AA%E5%A4%96%E7%B7%A8，
特にこのページの中の、音声も含んだ多段中継の実験ｓｅｌｆ／ｒｅｌａｙ．ｈｔｍｌ）に詳しいので、ここでの詳細な説明は省略する。
【００３９】
具体的にどのように構築するかについて、図４と図８に即して説明する。
【００４０】
図４の配信システムがＷｅｂＲＴＣで構築されているものとする。今、配信先端末１０２に注目する。
【００４１】
配信先端末１０２は、配信元端末１０１と接続されており、配信先端末１０３および１０４に接続されている。これらの接続は、配信先端末１０２の上で動いているソフトウェアではそれぞれＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトのインスタンスとして表現されている。
【００４２】
図８は、配信先端末１０２の上で動いているソフトウェアを図示したものである。これは必ずしもＷｅｂブラウザで動くものに限定されるものではないが、ここでは説明の都合上Ｗｅｂブラウザで動いているものとする。
【００４３】
今、図４の配信元端末１０１から配信先端末１０２に対してすでに映像音声が伝送されているものとしよう。そのとき、図８の上流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０１を通してＡＬＭノード制御ソフトウェア５０２には、それら映像音声を表すＭｅｄｉａＳｔｒｅａｍＴｒａｃｋオブジェクトがｏｎｔｒａｃｋイベントを通して提供される。なお、これは、参考文献４（ＷｅｂＲＴＣ１．０：Ｒｅａｌ−ｔｉｍｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｂｅｔｗｅｅｎ  Ｂｒｏｗｓｅｒｓ，https://www.w3.org/TR/webrtc）で説明される仕様に基づく説明で、現状のＧｏｏｇｌｅ  Ｃｈｒｏｍｅの実装ではＭｅｄｉａＳｔｒｅａｍオブジェクトがｏｎａｄｄｓｔｒｅａｍイベントを通して提供される。
【００４４】
映像音声の再配信を行わず、配信先端末１０２の上で単に再生するだけであれば、それをＨＴＭＬ５のｖｉｄｅｏ要素に関連付けることで、図４の配信元端末１０１から送信された映像音声を再生することができる。しかし、図８の下流ＡＬＭノード制御ソフトウェア５０２はリレーを行うので、上流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０１から受け取ったＭｅｄｉａＳｔｒｅａｍＴｒａｃｋを、下流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０３及び５０４のオブジェクトに関連付けることでメディアリレーの実行を実行環境に指示する。
【００４５】
具体的には、ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎオブジェクトにはａｄｄＴｒａｃｋメソッドがあり、下流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０３及び５０４のインスタンスに対し、上流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０１から受け取ったＭｅｄｉａＳｔｒｅａｍＴｒａｃｋを引数として、そのａｄｄＴｒａｃｋを呼び出す。現状のＧｏｏｇｌｅ  Ｃｈｒｏｍｅの実装に即して実現するならば、下流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０３、５０４のａｄｄＳｔｒｅａｍメソッドを上流ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎ５０１から受け取ったＭｅｄｉａＳｔｒｅａｍオブジェクトを引数として呼び出す。これにより、図４の配信先端末１０３、１０４に対する再配信が指示される。
【００４６】
以上は、ＷｅｂＲＴＣ仕様におけるＡＰＩレベルでの説明であるが、実際にはＷｅｂブラウザの中ではこれらの操作に対応して、上流からの映像・音声ストリームの受信・デコード、コピー、下流への再エンコード・送出が実行される。
【００４７】
［ＩＣＥ（Ｖａｎｉllａ  ＩＣＥおよびＴｒｉｃｋｌｅ  ＩＣＥ）］
ＷｅｂＲＴＣで利用される技術の１つとして、ＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｅｓｔａｂlｉｓｈｍｅｎｔ）がある。これは、ＷｅｂＲＴＣを利用する端末がＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）装置を介してインターネットに接続している際に、相互接続性を確保するために利用される技術である。
【００４８】
ＮＡＴとは、２つ（以上）のネットワークインタフェースを備えた装置であり、１つはインターネット（ＷＡＮ）と、もう１つはプライベートネットワーク（たとえばイントラネットあるいは宅内のネットワーク）とつながっている。ＷＡＮ側のインターフェースにはインターネットで通用するグローバルＩＰアドレスが付与されている。プライベートネットワーク側のインターフェースにはプライベートＩＰアドレスが付与されている。ＩＰｖ４アドレスの枯渇に対応して弥縫策として登場した技術であるが、現実には現代のインターネットの基盤の１つになっている。
【００４９】
ＳＩＰやＷｅｂＲＴＣのシグナリングで想定されるｏｆｆｅｒ−ａｎｓｗｅｒプロトコルおよびＷｅｂＲＴＣのような端末同士が直接メディア通信を行う仕組みは、本来であればグローバルＩＰアドレスをもった端末同士、もしくは同一のプライベートネットワークに参加している端末同士でしか成立しない。それを、ＮＡＴ装置やＳＴＵＮサーバー（後述）などの助けを借りて、別のプライベートネットワークに参加している端末が相互に通信できるようにするための手順を定めたのがＩＣＥ仕様である。
【００５０】
この技術は参考文献５（ｄｒａｆｔ−ｉｅｔｆ−ｉｃｅ−ｒｆｃ５２４５ｂｉｓ−ｌ０−ＩｎｔｅｒａｃｔｉｖｅＣｏｎｎｅｃｔｉｖｉｔｙ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ，（ＩＣＥ）：Ａ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｒａｖｅｒｓａｌ，https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-10），参考文献６（ｄｒａｆｔ−ｉｅｔｆ−ｉｃｅ−ｔｒｉｃｋｌｅ−１３−Ｔｒｉｃｋｌｅ  ＩＣＥ：Ｉｎｃｒｅｍｅｎｔａｌ  Ｐｒｏｖｉｓｉｏｎｉｎｇ  ｏｆ  Ｃａｎｄｉｄａｔｅｓ  ｆｏｒ  ｔｈｅ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＩＣＥ）Ｐｒｏｔｏｃｏｌ，https://tools.ietf.org/html/draft-ietf-ice-trickle-13）で開示されるものであるが、本発明の説明の都合上、必要な範囲に限定して説明する。
【００５１】
図９〜図１２は、ビデオ通話（あるいはメディア配信）を行う２台の端末（発呼ノード６０１および、着呼ノード６０２）が、ＮＡＴ装置６１１、６１２を介して（あるいは介さずに）インターネットに接続されている様子を示したものである。
【００５２】
図９は、発呼ノード６０１と着呼ノード６０２のそれぞれが別のプライベートネットワークに属しており、それぞれのプライベートネットワークがインターネット６４１にＮＡＴ装置６１１および６１２を介して接続されている様子を示す。シグナリングサーバー６３１はインターネット６４１上にあるものとする（図９〜図１２で以下同様）。ＳＴＵＮサーバー６２１、６２２は同一のものであってもよいが、説明をわかりやすくするために、それぞれ別のものとして描いている（以下同様）。
【００５３】
発呼ノード６０１と着呼ノード６０２は直接相手のローカルインターフェースに付与されたアドレスを指定して通信することはできず、ＮＡＴ装置６１１および６１２のＷＡＮ側に付与されたグローバルＩＰアドレスを指定してメディア通信することになる。ＮＡＴは、その際送信元あるいは受信先のフライベートＩＰアドレスをＮＡＴのＷＡＮ側に付与されたグローバルＩＰアドレスに変換し、また場合によってはポート番号も変換する。したがってメディアストリームは、６９１で示した経路を通る必要が有る。この経路６９１を発見するために発呼ノード６０１と着呼ノード６０２とはＳＴＵＮサーバー６２１および６２２を用いてＮＡＴ装置６１１および６１２のＷＡＮ側に付与されたグローバルＩＰアドレス（ｓｅｒｖｅｒ  ｒｅｆｌｅｘｉｖｅ  ａｄｄｒｅｓｓとよぶ）を発見し、シグナリングサーバー６３１を介して知り得た情報を交換し、経路の疎通を総当たり的に確認する。この手順はＩＣＥ仕様で定められたものの一部であり、後述する。
【００５４】
図１０は、発呼ノード６０１、ＮＡＴ装置６１１、ＳＴＵＮサーバー６２１、シグナリングサーバー６３１は図９と同様であるが、着呼ノード６０２は当該ホストが持つネットワークインタフェースにグローバルＩＰアドレスが付与されており、インターネット６４１に直接参加している形態である。この場合、可能なメディアストリーム経路は６９２のようになり、１台のＮＡＴ装置６１１だけが発呼ノード６０１と着呼ノード６０２との間に介在するものになる。
【００５５】
図１１は、発呼ノード６０１および着呼ノード６０２のいずれにもグローバルＩＰアドレスが付与されており、そのため６４１インターネットを介して直接通信できる形態である。
【００５６】
図１２は、発呼ノード６０１および着呼ノード６０２の両方が同一のプライベートネットワークに参加しているため、それぞれのプライベートＩＰアドレスを使って直接通信できる形態である。
【００５７】
図１１、図１２は、結果的にはメディア通信にＮＡＴ装置が介在しない形態になる。実際には、図９〜図１２のどの形態になっているかを、まだ通信を開始していない状態で発呼ノード６０１あるいは着呼ノード６０２が知ることはできない。
【００５８】
そのような状態から、ＳＴＵＮサーバー６２１、６２２の助けを借りて可能な経路（図９〜図１２に示す各経路６９１〜６９４）を発見するのが、以下で説明するＩＣＥ手順の目的である。なおＩＣＥ手順には一般には上記に挙げたもの以外にＴＵＲＮサーバーと呼ばれるものが介在し得るが、ここでは説明しない。
【００５９】
ところでＩＣＥ手順には、通常の１ＣＥ（非特許文献５）と、それを改良した高速な手順であるＴｒｉｃｋｌｅ  ＩＣＥと呼ばれる手順（非特許文献６）とがある。ここではＴｒｉｃｋｌｅ  ＩＣＥについて説明する。
【００６０】
図１３、図１４は、Ｔｒｉｃｋｌｅ  ＩＣＥの手順を示すシーケンス図である。
【００６１】
図１３において、ＳＴＵＮサーバー６２１、発呼ノード６０１、シグナリングサーバー６３１、着呼ノード６０２、ＳＴＵＮサーバー６２２は、図９〜図１２に記載したものと同じである。
【００６２】
実際のシステムの展開状況が、例えば図９〜図１２のいずれであるかは、発呼ノード６０１や着呼ノード６０２にとっては既知の情報ではなく、実際それはＩＣＥ手順を通して検知しょうとしている情報の一部である。
【００６３】
ステップ（１００１）、（１００２）において、発呼ノード６０１はシグナリングサーバー６３１を介して、着呼ノード６０２に接続要求を送出する。その接続要求を受けて、着呼メード６０２は（１００３）及び（１００４）のステップを実行する。それぞれ以下に説明する。
【００６４】
ステップ（１００３）及び（１００５）では、着呼ノード６０２はシグナリングサーバー６３１を介して発呼ノード６０１にｏｆｆｅｒ及びＩＣＥ  ｃａｎｄｉｄａｔｅ（ｈｏｓｔ）を送出する。
【００６５】
ここで、ｏｆｆｅｒは、各ノード間の能力交換のための情報（使用するｃｏｄｅｃの提案など）を含む情報であり、それと一緒にＩＣＥの候補アドレスの１つとして着呼ノード６０２自身のアドレスを送信する。ｏｆｆｅｒを提案情報とも呼び、ＩＣＥ  ｃａｎｄｉｄａｔｅを接続候補情報とも呼ぶ。
【００６６】
なお、ｏｆｆｅｒとＩＣＥ  ｃａｎｄｉｄａｔｅを一緒に送信するかどうかはＴｒｉｃｋｌｅ  ＩＣＥにおいてはブラウザ実装依存であり、別個に送信することもあり得る。また、ｏｆｆｅｒが発呼側から送出されるか着呼側から送出されるかはシグナリング実装依存であり、発呼側から送出されるような実装にすることが多いと思われるが、ここでは着呼ノード６０２から出るものとしている。
【００６７】
一方並行して（１００４）のステップで、着呼ノード６０２はＳＴＵＮサーバー６２２にＳＴＵＮ  ｂｉｎｄｉｎｇ  ｒｅｑｕｅｓｔを送出する。図１３のシーケンス図では明示していないが、システムの展開状況が図９、図１１のようなものであれば、６２２に対する送出経路はＮＡＴ装置（図９ではＮＡＴ装置６１２、図１２ではＮＡＴ装置６１１）を介在することになる。この要求は、ＳＴＵＮサーバー６２２に対して着呼ノード６０２のｓｒｆｌｘ（ｓｅｒｖｅｒ  ｒｅｆｌｅｘｉｖｅ）アドレスの収集を指示するものとなる。ここで、ｓｒｆｌｘアドレスとはＳＴＵＮサーバー６２２から見たＳＴＵＮ  ｂｉｎｄｉｎｇ  ｒｅｑｕｅｓｔの送信元の（グローバル）アドレスであり、システムの展開状況が図９、図１２のように通信経路にＮＡＴ装置が介在している場合であればＮＡＴ装置のＷＡＮ側のアドレス、図１０、図１１のように介在していない場合であれば着呼ノード６０２のアドレスとなる。ＳＴＵＮサーバー６２２は後のステップ（１０１１）で収集したｓｒｆｌｘアドレスを着呼ノード６０２に返す。
【００６８】
また、ステップ（１００５）で、ｏｆｆｅｒ及びＩＣＥ  ｃａｎｄｉｄａｔｅ（ｈｏｓｔ）を受けた発呼ノード６０１は（１００６）および（１００７）のステップを実行する。それぞれ以下に説明する。
【００６９】
（１００６）のステップで、発呼ノード６０１はＳＴＵＮサーバー６２１にＳＴＵＮ  ｂｉｎｄｉｎｇ  ｒｅｑｕｅｓｔ、すなわちｓｒｆｌｘアドレスの収集要求を送出する。これは着呼ノード６０２での（１００４）のステップの動作と同様である。システムの展開状況が図９、図１０、図１２のようなものであれば、ＳＴＵＮサーバー６２１に対する送出経路はＮＡＴ装置６１１を介在することになり、ＳＴＵＮサーバー６２１で収集されるｓｒｆｌｘアドレスはＮＡＴ装置６１１のＷＡＮ側のアドレスである。また図１１の場合はＮＡＴ装置が介在しておらず、収集されるアドレスは発呼ノード６０１のアドレスとなる。ＮＡＴ装置６１１は収集したｓｒｆｌｘアドレスを後のステップ（１０１６）で発呼ノード６０１に返す。
【００７０】
一方並行して（１００７）および（１００８）のステップで、発呼ノード６０１はシグナリングサーバー６３１を介して着呼ノード６０２にａｎｓｗｅｒ及びＩＣＥ  ｃａｎｄｉｄａｔｅ（ｈｏｓｔ）を送出する。ここで、ａｎｓｗｅｒは能力交換のための情報で、通常ｏｆｆｅｒに含まれる情報のサブセットである。ａｎｓｗｅｒを回答情報とも呼ぶ。ＩＣＥ  ｃａｎｄｉｄａｔｅには発呼ノード６０１自身のアドレスを提示する。ただしａｎｓｗｅｒとＩＣＥ  ｃａｎｄｉｄａｔｅ（ｈｏｓｔ）とが単一のメッセージで送信されるか複数に分割されるかが任意であるのは、ステップ（１００３）および（１００５）と同様である。
【００７１】
さて、（１００８）のステップで、発呼ノード６０１と着呼ノード６０２の双方で相手のｈｏｓｔアドレスが知られた状態になるので、それを受けた（１００９）のステップで、発呼ノード６０１と着呼ノード６０２との間でＩＣＥ接続確認（発呼ｈｏｓｔ−着呼ｈｏｓｔ）を試みる。システムの展開状況が図１１もしくは図１２のようなものであったならば、この段階（ステップ１０１０）で接続が確立する。
【００７２】
確立した場合は以下の手順は行う必要がない。しかしそうでなかった場合はＴｒｉｃｋｌｅ  ＩＣＥにおける情報収集・交換は以下のように続く。
【００７３】
（１０１１）のステップでは、上述の（１００４）の要求によってＳＴＵＮサーバー６２２は着呼ノード６０２にｓｒｆｌｘアドレス（着呼ノード６０２のＷＡＮ側のアドレス）を返信する。
【００７４】
それを受けて（１０１２）のステップでは、着呼ノード６０２はシグナリングサーバー６３１を介して発呼ノード６０１に対してＩＣＥ  ｃａｎｄｉｄａｔｅ（ｓｒｆｌｘ）を送出する。ここで発呼ノード６０１に渡るのは、着呼ノード６０２のｓｒｆｌｘアドレス（上述）である。
【００７５】
これで発呼ノード６０１と着呼ノード６０２の間で発呼ノード６０１のｈｏｓｔアドレス並びに着呼ノード６０２のｓｒｆｌｘアドレスの情報が共有されている状態になったので、図１４のステップ（１０１４）では発呼ノード６０１と着呼ノード６０２との間でＩＣＥ接続確認（発呼ｈｏｓｔ−着呼ｓｒｆｌｘ）を試みる。もしうまくいけば、ステップ（１０１５）で発呼ノード６０１と着呼ノード６０２との間で接続確立する。具体的には図１０において発呼側・着呼側が入れ替わった配置になっていた場合はこのタイミングで接続確立することが考えられる。
【００７６】
確立した場合は以下の手順は行う必要がない。しかしそうでなかった場合はＴｒｉｃｋｌｅ  ＩＣＥにおける情報収集・交換は以下のように続く。
【００７７】
（１０１６）のステップでは、上述の（１００６）の要求によってＳＴＵＮサーバー６２１は発呼ノード６０１にｓｒｆ１ｘアドレス（発呼ノード６０１のＷＡＮ側のアドレス）を返信する。
【００７８】
それを受けて（１０１７）、（１０１８）のステップでは発呼ノード６０１はシグナリングサーバー６３１を介して着呼ノード６０２にＩＣＥ  ｃａｎｄｉｄａｔｅ（ｓｒｆｌｘ）を送出する。ここで着呼ノード６０２に渡るのは発呼ノード６０１のｓｒｆｌｘアドレス（上述）である。
【００７９】
これで発呼ノード６０１と着呼ノード６０２の間で発呼ノード６０１のｈｏｓｔアドレス、ｓｒｆｌｘアドレス、着呼ノード６０２のｈｏｓｔアドレス、ｓｒｆｌｘアドレスの情報が共有されている状態になったので、ステップ（１０１９）および、（１０２１）の確認が実行できるようになっている。
【００８０】
ステップ（１０１９）では発呼ノード６０１と着呼ノード６０２との間でＩＣＥ接続確認（発呼ｓｒｆｌｘ−着呼ｈｏｓｔ）を試みる。うまく接続できれば（１０２０）発呼ノード６０１と着呼ノード６０２との間で接続確立する。具体的には図９の配置になっていた場合はこのタイミングで接続確立することが考えられる。
【００８１】
並行して（もしくは上記が失敗すれば）ステップ（１０２１）で、発呼ノード６０１と着呼ノード６０２との間でＩＣＥ接続確認（発呼ｓｒｆｌｘ−着呼ｓｒｆｌｘ）を試みる。うまく接続できれば、ステップ（１０２２）で、発呼ノード６０１と着呼ノード６０２との間で接続確立する。具体的には図９の配置になっていた場合はこのタイミングで接続確立することが考えられる。
【００８２】
それでもうまくいかなければ、ステップ（１０２３）で、発呼ノード６０１と着呼ノード６０２との間で接続失敗したことになる。原因としては、例えば、図９あるいは図１０の配置（あるいは図１０において発呼側・着呼側が入れ替わった配置）のようになっているが、経路上のＮＡＴ装置が何らかの理由でメディアストリームを通さないものになっていることが考えられる。
【００８３】
以上のように、ノード間（例えば、上記の例では、発呼ノード６０１、着呼ノード６０２の間）の接続を確立するために、ＮＡＴ装置（６１１，６１２）のＷＡＮ側のアドレスを含めたアドレスを含めて、両者のアドレスの組み合わせを総当たりで確認することでどの組み合わせ（経路）が最もよく機能するかを確認するのがＩＣＥ手順である。実際には、ＮＡＴのＷＡＮアドレス経由で接続するようにするためには、ステップ（１０１４），（１０１９），（１０２１）のＩＣＥ接続確認の過程において両ノード間でＨｏｌｅ  Ｐｕｎｃｈｉｎｇを実行してＮＡＴ装置がＷＡＮ側からの接続要求に呼応したアドレス・ポート変換を適切に行うようにすることが重要なのであるが、ここでは説明しない。
【００８４】
なお、Ｔｒｉｃｋｌｅ  ＩＣＥでない従来のＩＣＥでは両ノードで利用可能なアドレスをすべて収集した段階で接続確認の総当たりを実行する。
【００８５】
それに対し、上記で説明したＴｒｉｃｋｌｅ  ＩＣＥでは利用可能なアドレスの組が１つできるたびに接続確認を逐次行っていき、一番早く接続できた組で接続経路とし、それ以降の手順を省略できる（すなわち、接続に要する時間が短くなる）点を特徴としている。
【００８６】
また、ここでは説明しなかったが、Ｈｏｓｔインターフェースを複数持つ端末（ＶＰＮ接続の仮想インターフェースのようなものも含む）では、それぞれのインターフェースに付与されたアドレスを使って上述の「総当たり」を実行することになる。Ｔｒｉｃｋｌｅ  ＩＣＥの場合は通常その中で一番早くつながった組み合わせで接続することになる。
【００８７】
（Ａ−１）実施形態の構成
以下に、本発明の実施形態の構成を、図面を参照しながら説明する。
【００８８】
図３は、実施形態に係る通信装置接続システムの全体構成を示す図である。
【００８９】
図３に示す通信装置接続システムは、マルチキャスト通信が行われる木構造（ツリー状）のネットワークであり、通信装置を接続する通信装置接続システムである。
【００９０】
図３は、図４と同様に、オーバーレイネットワークレベルでのメディアストリームの配信経路を示すものであり、実際のネットワーク接続は、例えば図５と同様のものになる。
【００９１】
図３の例では、通信装置接続システム１０００は、配信元端末１１０１、既存ノード１１０２〜１１０７、接続サーバーとしてのシグナリングサーバー１１１０を有しており、ここでは、既存ノード１１０２〜１１０７で構成されるネットワークに、新規ノード１１０９が参加しようとする場合を想定している。
【００９２】
配信元端末１１０１は、映像や音声などを含むメディアデータを配信する配信元の端末である。配信元端末１１０１は、例えば、ビデオカメラ等を装備しており、その映像や音声などを既存ノード１１０２〜１１０７から構成されるＡＬＭを通して配信する。配信元端末１１０１は、図４の配信元端末１０１と同等の端末である。
【００９３】
既存ノード１１０２〜１１０７は、配信元端末１１０１から配信されるメディアデータを視聴するための配信先端末であり、ＡＬＭを構成しているものである。既存ノード１１０２〜１１０７は、図４の配信先端末１０２〜１０７と同等の端末である。
【００９４】
新規ノード１１０９は、既存ノード１１０２〜１１０７と同様の端末であるが、図４に示したＡＬＭ（ネットワーク）にまだ参加しておらず、これから参加して映像を視聴しようとしているものとする。
【００９５】
ＡＬＭに新規参加する際、新規ノード１１０９が、既存ノード１１０２〜１１０７のうち、どの既存ノードに接続してＡＬＭに参加するか決めねばならない。
【００９６】
ここでは、通信装置接続システム１０００において、既存ノード１１０４と既存ノード１１０７のいずれかを接続先ノード候補として選択し、提示しているものと仮定して説明する。すなわち、この実施形態の例では、新規ノード１１０９の接続に際して、既存ノード１１０４あるいは既存ノード１１０７のいずれに接続するかを決定する場合を説明する。
【００９７】
また、この実施形態では、説明を容易にするため、既存ノード１１０４及び１１０７のうち、一方の既存ノード１１０４のことを「既存ノード１」、他方の既存ノード１１０７のことを「既存ノード２」と表記して説明することもある。
【００９８】
なお、本発明はＮＡＴトラバーサル自体を課題にするものではないので、説明を簡単にするため、各ノード１１０２〜１１０９は、図４〜図７に示す各端末（あるいは図９〜図１４に示す発呼ノード６０１、着呼ノード６０２）等と同様に、グローバルＩＰアドレスを付与されているか、もしくは同一のプライベートネットワークに属するものとする。ただしトランスポートネットワークは図５と同様ルーター等でいくつかに分割され、新規ノード１１０９からみたルーターホップ数が１１０４と１１０７とでは異なることを想定している。
【００９９】
図３における既存ノード１１０２〜１１０７及び新規ノード１１０９の上で動いているＷｅｂアプリケーション内部の概念的な構成は図８と同様であり、各ノード上でＡＬＭ制御ソフトウェア５０２が動作している。
【０１００】
ただし、ＡＬＭ制御ソフトウェア５０２で動いているロジックは後述の図１及び図２の手順を実現するものになる。
【０１０１】
そのＷｅｂアプリケーションを実行するＷｅｂブラウザは、ここでは話を簡単にするために、既存ノード１１０２〜１１０７及び新規ノード１１０９でほぼ同じもの（たとえばＧｏｏｇｌｅ  Ｃｈｒｏｍｅの同一の版数）を使っており、ｃｏｄｅｃ等の能力情報に大きな差が出ないようにしているものと仮定する。すなわち、各ノード１１０２〜１１０７又は１１０９が、どこに接続してもコーデックの違いなどでは大きな損をすることはないと仮定する。
【０１０２】
（Ａ−２）実施形態の動作
図１及び図２は、実施形態に係る通信装置接続処理を示すシーケンス図である。
【０１０３】
この実施形態に係る通信装置接続方法の概念を簡単に説明すると、Ｔｒｉｃｋｌｅ  ＩＣＥでは相手先の端末の持つ複数の接続候補アドレス（ｈｏｓｔ（通常１つであるが、一般には複数である）、ｓｒｆｌｘ、ｒｅｌａｙ）のいずれがつながりやすいか、総当たりで接続確認を行い、早い段階でうまく行った接続を採用するが、この実施形態では、その仕組みを流用して、複数の接続先のうち、１番早い段階でつながったものを採用するというものである。ただし、ＩＣＥのスタックにも手を入れる必要が有ると思われる。
【０１０４】
図１及び図２では、新規ノード１１０９、シグナリングサーバー１１１０、既存ノード１１０４（「既存ノード１」とも表記する。）、既存ノード１１０７（「既存ノード２」とも表記する。）は、図３に示したものと同一である。
【０１０５】
ステップ（１２０１）では、新規ノード１１０９はシグナリングサーバー１１１０に接続要求を送出する。
【０１０６】
ステップ（１２０２）では、接続要求を受けてシグナリングサーバー１１１０は、図１に示した既存ノード１１０２〜１１０７の中から、適切な接続先を選択する。ここでは既存ノード１１０４（既存ノード１）、既存ノード１１０７（既存ノード２）の２つが選ばれたものとする。接続先の選択数は、２つに限定されるものではないが、ここでは２つとして説明する。接続先の選択ロジックは、実施形態では特定はしないが、例えば、各ノード１１０２〜１１０７のホストＩＰｖ４アドレスの値をＫ−ｍｅａｎｓで分類して作ったグループごとにランダムに選ぶなど、適当に新規ノード１１０９から見たルーターホップ数が分散するようなロジックを利用することを適用できる。そうして、シグナリングサーバー１１１０は、既存ノード１１０４（既存ノード１）と既存ノード１１０７（既存ノード２）を候補として選択したものとする。
【０１０７】
ステップ（１２０３）及び（１２０５）で、シグナリングサーバー１１１０は既存ノード１１０４（既存ノード１）と既存ノード１１０７（既存ノード２）とのそれぞれに接続候補選択通知を送出する。これは、新規ノード１１０９からの接続候補になったことを各既存ノード１１０４及び１１０７に通知するものである。
【０１０８】
これを受けて、ステップ（１２０４）と（１２０６）では、既存ノード１１０４（既存ノード１）および既存ノード１１０７（既存ノード２）はシグナリングサーバー１１１０にｏｆｆｅｒ（提供情報）及びＩＣＥ  ｃａｎｄｉｄａｔｅ（通信経路候補情報）を送出する。これは、既存ノード１１０４及び１１０７としては、新規ノード１１０９に対してシグナリングチャネルを通してｏｆｆｅｒ／ＩＣＥ  ｃａｎｄｉｄａｔｅを送出したのと同じである。しかし、通常のシグナリングと異なり、シグナリングサーバー１１１０は新規ノード１１０９にそれをそのまま転送することはしない。その代わりにステップ（１２０７）で後述の処理を行い、処理結果をステップ（１２０８）で新規ノード１１０９に対して送信する。
【０１０９】
まず、ステップ（１２０７）で、ステップ（１２０４）及び（１２０６）で受領したｏｆｆｅｒ／ＩＣＥ  ｃａｎｄｉｄａｔｅのうち、ｏｆｆｅｒに含まれる能力情報を取り出して両者の共通部分を取る。またＩＣＥ  ｃａｎｄｉｄａｔｅに関する情報を、あたかも１つのホストの複数のネットワークインタフェースであるかのようにまとめる。
【０１１０】
ステップ（１２０８）では、シグナリングサーバー１１１０は新規ノード１１０９にｏｆｆｅｒ（共通部分）、ＩＣＥ  ｃａｎｄｉｄａｔｅ（既存１ｈｏｓｔ，既存２ｈｏｓｔ）を送出する。これは、（１２０７）のステップで作成した、（１２０４）と（１２０６）で受領した能力情報の共通部分、およびＩＣＥ  ｃａｎｄｉｄａｔｅをまとめたものである。
【０１１１】
それを受け、ステップ（１２０９）で、新規ノード１１０９はシグナリングサーバー１１１０にａｎｓｗｅｒ（回答情報）及びＩＣＥ  ｃａｎｄｉｄａｔｅ（新規ｈｏｓｔ）を送出する。
【０１１２】
ステップ（１２０９）のａｎｓｗｅｒおよびＩＣＥ  ｃａｎｄｉｄａｔｅを、シグナリングサーバー１１１０は相手先に転送するわけであるが、実際には相手先は接続候補として選択した既存ノード１１０４（既存ノード１）および既存ノード１１０７（既存ノード２）の両方である。（１２１０）（１２１２）の両ステップがその転送に相当する。
【０１１３】
ステップ（１２１０）の段階で、新規ノード１１０９と既存ノード１１０４（既存ノード１）は互いのｈｏｓｔアドレスを知っている状態になるので、両ｈｏｓｔアドレス間でＩＣＥ接続確認（新規ｈｏｓｔ−既存１ｈｏｓｔ）を試みる。それがステップ（１２１１）である。
【０１１４】
またステップ（１２１２）の段階で、新規ノード１１０９と既存ノード１１０７（既存ノード２）は互いのｈｏｓｔアドレスを知っている状態になるので、両ｈｏｓｔアドレス間でＩＣＥ接続確認（新規ｈｏｓｔ−既存２ｈｏｓｔ）を試みる。それがステップ（１２１３）である。
【０１１５】
並行して走るステップ（１２１１）とステップ（１２１３）は、両方が疎通確認に成功し得るわけであるが、ネットワーク的な距離（ｒｏｕｎｄ−ｔｒｉｐ  ｔｉｍｅで測られるようなもの）の関係でどちらかが先に疎通すると考えられる。
【０１１６】
仮にステップ（１２１１）における既存ノード１１０４（既存ノード１）との疎通確認が先に完了したとすると、ステップ（１２１４）で、新規ノード１１０９と既存ノード１１０４（既存ノード１）との間で接続確立する。それを受けてステップ（１２１５）で、既存ノード１１０４（既存ノード１）はシグナリングサーバー１１１０に接続確立検出を送出する。それを受けて、ステップ（１２１６）で、シグナリングサーバー１１１０は既存ノード１１０７（既存ノード２）に接続候補解放を送出する。既存ノード１１０７（既存ノード２）において、もしまだ接続を試行しているようなら接続試行を停止する。
【０１１７】
そうでなくて、ステップ（１２１３）における既存ノード１１０７（既存ノード２）との疎通確認が先に完了したとすると、ステップ（１２１７）で、新規ノード１１０９と既存ノード１１０７（既存ノード２）との間で接続確立し、それを受けて、ステップ（１２１８）で、既存ノード１１０７（既存ノード２）はシグナリングサーバー１１１０に接続確立検出を送出する。それを受けて、ステップ（１２１９）で、シグナリングサーバー１１１０は既存ノード１１０４（既存ノード１）に接続候補解放を送出する。既存ノード１１０４（既存ノード１）において、もしまだ接続を試行しているようなら接続試行を停止する。
【０１１８】
（Ａ−３）実施形態の効果
以上のように、実施形態に係る通信装置接続処理によれば、以下のような効果を奏する。
【０１１９】
一般にＪａｖａＳｃｒｉｐｔベースのＷｅｂアプリケーションでは、それ自身がソケットプログラミングを行うものではないことも有り、ＡＬＭで必要なネットワーク統計情報を取得することは難しい。
【０１２０】
ＷｅｂＲＴＣで他の端末とつながっている状態であればある程度とその接続に関する統計情報を得ることができる（それはＲＴＣＰなどを元にした情報である）が、すでにつながっている状態を前提にしており、一般的にはこれからＡＬＭに参加する端末で動くＷｅｂアプリケーションにとって利用可能な情報ではない。
【０１２１】
これに対して、本実施形態によれば、ブラウザ内部にＷｅｂＲＴＣスタックの一部として実装されているＩＣＥが備える複数ＩＰアドレス間での接続試行をＪａｖａＳｃｒｉｐｔコードの介在なしで実行する仕組みを流用して、より速くつながる接続相手を選択することが可能になる。
【０１２２】
ただし、ＩＣＥ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｃｈｅｃｋで用いるＳＴＵＮ  Ｂｉｎｄｉｎｇ  Ｒｅｑｕｅｓｔの認証の仕組みを変更して、新規ノード１１０９が既存ノード１１０４（既存ノード１）と既存ノード１１０７（既存ノード２）との違いを意識しないように手を入れる必要はある。
【０１２３】
（Ｂ）他の実施形態
上述した実施形態では、映像音声等のメディアストリームの配信に適用することを念頭に説明しているが、映像音声に限定されるものではなく、ホワイトボード共有のようなデータ配信にも適用可能である。ＷｅｂＲＴＣで実装する場合、ＤａｔａＣｈａｎｎｅｌを利用することになる。
【符号の説明】
【０１２４】
１０００…通信装置接続システム、１１０１…配信元端末、１１０２〜１１０７…既存ノード、１１０９…新規ノード、１１１０…シグナリングサーバー、５０２…ＡＬＭ制御ソフトウェア。
【図１】
2019145916.tif 000003
【図２】
2019145916.tif 000004
【図３】
2019145916.tif 000005
【図４】
2019145916.tif 000006
【図５】
2019145916.tif 000007
【図６】
2019145916.tif 000008
【図７】
2019145916.tif 000009
【図８】
2019145916.tif 000010
【図９】
2019145916.tif 000011
【図１０】
2019145916.tif 000012
【図１１】
2019145916.tif 000013
【図１２】
2019145916.tif 000014
【図１３】
2019145916.tif 000015
【図１４】
2019145916.tif 000016