(57)【要約】      （修正有）【課題】第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードと第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノードとの間で遠隔通信コールを生成する。【解決手段】第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードは、第１ネットワークとは異なる第２ネットワークのオーディオストリーム及びビデオストリームを有するソースノードと通信を行う。例えば、ＡＴＭネットワークの各ストリーミング能力を有する第１ノードと、ＬＡＮのオーディオストリーム能力とビデオストリーム能力有する第２ノードとの２地点間のびディオコールの場合、第１ノードは、最初に、インバイト信号をＡＴＭネットワークワークのサーバへ送信することで遠隔通信システムを構築する。【選択図】  図１
2005039803.tif 000002
【特許請求の範囲】
【請求項１】
遠隔通信コールを生成する方法であって、
第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードから、第１ノードとは異なる第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノードへコールするステップ、
第１ノード及び第２ノードの間でオーディオストリーム及びビデオストリームの通信が互いに行われるように、第１ノードと第２ノードの間でコールを生成するステップ、を有している方法。
【請求項２】
前記コールに、第１ネットワークのオーディオストリーム及びビデオストリームを有する第３ノードを追加するステップを含んでおり、、第１ノード、第２ノード及び第３ノードの間で、オーディオストリーム及びビデオストリームの通信が互いに行われ、第１ノード、第２ノード及び第３ノードの間で会議を行なうことができる請求項２に記載の方法。
【請求項３】
第３ノードを追加するステップは、会議を開くために、ホストノードと通信を行なうステップを含んでいる請求項２に記載の方法。
【請求項４】
生成ステップは、第１ノードとゲートウエイとの間でコールの第１接続を終了し、ゲートウエイと第２ノードとの間でコールの第２接続を作成し、第１接続からのデータは、ゲートウエイから第２ノードへ送られる請求項３に記載の方法。
【請求項５】
第２ノードと、オーディオストリームだけを有する第４ノードとの間で、ゲートウエイ及びオーディオミキサーを通じて通信を行なうステップを含んでいる請求項４に記載の方法。
【請求項６】
遠隔通信システムであって、
第１ネットワークと、
第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードと、
第１ネットワークとは異なる第２ネットワークと、
第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノードと、
第１ノードと第２ノードの間でオーディオストリーム及びビデオストリームの通信が互いに行われるように、第１ノードと第２ノードとの間でコールを生成する手段、を具えているシステム。
【請求項７】
オーディオストリームとビデオストリームを有する第３ノードを含んでおり、生成手段は、第１ノード、第２ノード及び第３ノードの間で会議を接続するゲートウエイを含んでおり、第１ノード、第２ノード及び第３ノードの間でオーディオ遠隔ストリーム及びビデオ遠隔ストリームの通信が互いに行われる請求項６に記載のシステム。
【請求項８】
ホストノードを含んでおり、ゲートウエイは前記ホストノードと通信する請求項７に記載のシステム。
【請求項９】
ゲートウエイは、第１ノードとゲートウエイの間でコールの第１接続を終了し、ゲートウエイと第２ノードの間でコールの第２接続を作成し、第１接続からのデータは、ゲートウエイから第２ノードへ送られる請求項８に記載のシステム。
【請求項１０】
第１ネットワークと、オーディオストリームだけを有する第４ノードとに連繋されたオーディオミキサーを含んでおり、第２ノードは、ゲートウエイ及びミキサーを通じて、第４ノードと通信を行なう請求項９に記載のシステム。
【請求項１１】
ゲートウエイは、少なくとも第１ネットワークのインターフェースカードを含んでおり、該カードを通じて、ゲートウエイは第１ネットワークと通信する請求項１０に記載のシステム。
【請求項１２】
ゲートウエイは、第２ネットワークのインターフェースカードを含んでおり、該カードを通じて、ゲートウエイは第２ネットワークと通信する請求項１１に記載のシステム。
【請求項１３】
ゲートウエイは、第１ノード、第２ノード及び第３ノードのオーディオストリーム及びビデオストリームを保持するメモリを含んでいる請求項１２に記載のシステム。
【請求項１４】
第１ノードはアドレスを有し、第２ノードはアドレスを有し、第３ノードはアドレスを有しており、第１ノード、第２ノード及び第３ノードの間は接続されており、メモリは、第１ノード、第２ノード及び第３ノードのアドレスを格納する請求項１３に記載のシステム。
【請求項１５】
第１ネットワークはＡＴＭネットワークであり、第２ネットワークはＥｔｈｅｒｎｅｔネットワークである請求項１５に記載のシステム。
【請求項１６】
ゲートウエイはＰＣである請求項１５に記載のシステム。
【請求項１７】
第１ノードと第３ノードは、ＡＴＭネットワークの一部であり、第１ノード、第３ノード及びゲートウエイは、ＡＴＭネットワークを通じて、パケットを互いにマルチキャストする請求項１６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードと、第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノードとの間における遠隔通信コールの形成に関する。より具体的には、本発明は、第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードと、第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノードとの間で遠隔通信コールを生成し、ゲートウエイにより、第１ネットワークの第１ノードと第２ノードの第２ノードとの間を相互接続するようにしたものである。
【背景技術】
【０００２】
ＶｉＰｒシステムは、ＡＴＭ及びＩＰ／ＥｔｈｅｒｎｅｔのＬＡＮ／ＷＡＮ環境に配備される。ＡＴＭを通じて、ＶｉＰｒは１対多方向型の交換型仮想チャンネル(ＰＭＰ−ＳＶＣ)を用いて、ＶｉＰｒ端末間にオーディオ／ビデオトラフィックが運ばれる。ＶｉＰｒを配備するシナリオの中には、例えば前述の如く異種ネットワーク環境におけるＶｉＰｒ端末間で会議の開催を要求されることがある。一例として、ＡＴＭ−ＳＶＣベースのネットワークのＶｉＰｒ端末が、ＩＰ／ＥｔｈｅｒｎｅｔベースのネットワークのＶｉＰｒ端末と会議を行なう必要がある場合がある。その逆の場合もある。同様に、ＡＴＭ−ＳＶＣベースのコアによって相互接続された別個のＩＰ／ＥｔｈｅｒｎｅｔベースのＬＡＮｓのＶｉＰｒ端末が互いに会議(conference)を行なう場合がある。
もう１つの要求として、ＩＰマルチキャストを用いた別個のＩＰ／ＥｔｈｅｒｎｅｔベースのＬＡＮｓのＶｉＰｒ端末が、ＩＰマルチキャストを許可しないサービスプロバイダーのバックボーンを通して会議を行なうことがある。これらの場合、インターメディアゲートウエイ(ＩＭＧＷ)は、各環境内に必要なＱｏＳを保存しながら、異なるネットワーク環境の間で継ぎ目無くブリッジを作成する必要がある。ＩＭＧＷｓによって相互接続された異種ネットワーク環境におけるＶｉＰｒ端末は、まるで、それらの全てが同じＬＡＮ環境の中にあるかのように、途切れ無く会議を行なうことができる。
【０００３】
＜Ｈｙｂｒｉｄ  ＡＴＭ−ＳＶＣ及びＩＰ／Ｅｔｈｅｒｎｅｔの環境＞
これまで、ＩＰトラフィックは、ＬＡＮＥ又はＲＦＣ１４８３を用いて、ＡＴＭを通じて行われている。ＡＴＭをサポートする現在のストリーム及びルータは、ＡＴＭ  ＥＬＡＮを結合し、トラフィックをＩＰ／Ｅｔｈｅｒｎｅｔネットワークにルーティングするか、又は、ＲＦＣ１４８３接続を終了し、ＩＰトラフィックをＩＰ／Ｅｔｈｅｒｎｅｔネットワークへ転送することにより、ＡＴＭ及びＩＰ／Ｅｔｈｅｒｎｅｔの世界を接続する。ＡＴＭ−ＳＶＣベースのＶｉＰｒシステムにおいて、ＶｉＰｒ端末は、オーディオ／ビデオトラフィックをＲＴＰパケットの中に含むようにし、ＩＰ／ＵＤＰヘッダーを用いることなく、ＡＴＭ  ＳＶＣｓを通じて、ＡＡＬ−５ＰＤＵｓの中をトランスポートする。これは、ＩＰ／ＵＤＰヘッダーが無関係(irrevant)になる環境の中で帯域幅をセーブする役割を有する。しかしながら、ＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒストリームと会議を行なう必要があるときはいつでも、ＡＴＭ  ＳＶＣをＩＰ／Ｅｔｈｅｒｎｅｔアドレスに直接マッピングすることが必要になる。この機能は、現在利用可能なオフザシェルフ(off-the-shelf)のルータ及びスイッチではサポートされておらず、インターメディアゲートウエイを用いる必要がある。
【０００４】
＜Ｈｙｂｒｉｄ  ＩＰ／Ｅｔｈｅｒｎｅｔマルチキャスト及びユニキャストの環境＞
ＩＰ／Ｅｔｈｅｒｎｅｔ環境に配備されるとき、ＶｉＰｒシステムは、ＶｉＰｒ端末とビデオサーバとの間だけでなく、ＩＰマルチキャストに基づいて、会議コールのＶｉＰｒ端末にオーディオ／ビデオトラフィックを行なう。複数のＩＰ／ＥｔｈｅｒｎｅｔのＶｉＰｒアイランドが、ＩＰマルチキャストをサポートしないサービスプロバイダーのバックボーンによって相互接続されるようにＶｉＰｒが配置された場合、ＳＰのスペースを横切るには、オーディオ／ビデオＩＰマルチキャストストリームを、複数のＩＰユニキャストストリームへマップする必要がある。この機能は、現在利用可能なオフザシェルフのルータ及びスイッチではサポートされておらず、インターメディアゲートウエイを用いる必要がある。
【０００５】
従来のスイッチ／ルータを取り替えるために、ＶｉＰｒインターメディアゲートウエイ(ＩＭＧＷ)は、異種ネットワーク環境の中のＶｉＰｒ端末間で、途切れなくオーディオ／ビデオ会議を行なうことができるように設計されており、これは、まるで、全てが同じＬＡＮ環境にあるかのようである。
【０００６】
ＶｉＰｒインターメディアゲートウエイ(ＩＭＧＷ)は、次のように設計されている。
ａ）ＡＴＭ−ＳＶＣベースのＶｉＰｒ端末とＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒ端末との間で、端末をサポートし、ＡＴＭ  ＳＶＣｓのＩＰ／ＵＤＰソケットへ直接マッピングを行ない、またその逆の直接マッピングを行なうことにより、会議開催を可能とすること。
ｂ）ハイブリッドのＶｉＰｒ環境の中でビデオチャンネル(例えばＣＮＮ)のストリームを可能とすること。
【発明の開示】
【０００７】
本発明は、遠隔通信コール(telecommunications call)を生成する方法に関する。この方法は、第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードから、オーディオストリーム及びビデオストリームを有する第２ノードへコールするステップを有している。第１ノードと第２ノードがそれらのオーディオストリーム及びビデオストリームを互いに通信できるように、第１ノードと第２ノードとの間でコールを生成するステップがある。
【０００８】
本発明は遠隔通信システムに関する。このシステムは第１ネットワークを具えている。システムは、第１ネットワークのオーディオストリーム及びビデオストリームを有する第１ノードを具えている。システムは第２ネットワークを具えている。システムは、第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノードを具えている。システムは、第１ノードと第２ノードの間でそれらのオーディオストリーム及びビデオストリームが互いに通信されるように、第１ノードと第２ノードとの間でコールを生成する手段を具えている。
【０００９】
＜詳細な説明＞
図面を参照すると、幾つかの図において、同一又は同様な要素については同じ引用符号を付している。例えば、図１は、遠隔通信システム(10)を示している。システム(10)は第１ネットワーク(12)を具えている。システム(10)は、第１ネットワーク(12)のオーディオストリーム及びビデオストリームを有する第１ノード(16)を具えている。システム(10)は、第１ネットワークとは異なる第２ネットワーク(14)を具えている。システム(10)は、第２ネットワーク(14)のオーディオストリーム及びビデオストリームを有する第２ノード(18)を具えている。システム(10)は、第１ノード(16)と第２ノード(18)との間でコールを生成する手段(20)を具えており、第１ノード(16)と第２ノード(18)の間で、それらのオーディオストリーム及びビデオストリームの通信を互いに行なうことができる。
【００１０】
望ましくは、システム(10)は、オーディオストリーム及びビデオストリームを有する第３ノード(22)を含み、生成手段(20)は、第１ノード(16)、第２ノード(18)及び第３ノード(22)の間で会議を接続するゲートウエイを含んでおり、第１ノード(16)、第２ノード(18)及び第３ノード(22)の間で、オーディオ遠隔ストリーム及びビデオ遠隔ストリームの通信を互いに行なうことができる。
システム(10)は、ホストノード(20)を含むことが望ましく、ゲートウエイ(24)は、ホストノード(26)と通信する。ゲートウエイ(24)は、望ましくは、第１ノード(16)とゲートウエイ(24)との間でコールの第１接続を終了し、ゲートウエイ(24)と第２ノード(18)との間でコールの第２接続を生成し、第１接続のデータは、ゲートウエイ(24)から第２ノード(18)へ送られる。システム(10)は、第１ネットワーク(12)に連繋されたオーディオミキサー(28)と、オーディオストリームだけを有する第４ノードを含むことが望ましく、第２ノード(18)は、ゲートウエイ(24)及びミキサーを通じて、第４ノードと通信を行なうことが望ましい。
【００１１】
ゲートウエイ(24)は、少なくとも第１ネットワークのインターフェースカード(30)を含むことが望ましく、該カードを通じて、ゲートウエイ(24)は第１ネットワーク(12)との通信を行なう。ゲートウエイ(24)は、第２ネットワークのインターフェースカード(32)を含むことが望ましく、該カードを通じて、ゲートウエイ(24)は第２ネットワーク(14)との通信を行なう。ゲートウエイ(24)は、第１ノード(16)、第２ノード(18)及び第３ノード(22)のオーディオストリーム及びビデオストリームを保持するメモリを含むことが望ましい。
【００１２】
望ましくは、第１ノード(16)はアドレスを有し、第２ノード(18)はアドレスを有し、第３ノード(22)はアドレスを有しており、第１ノード(16)、第２ノード(18)及び第３ノード(22)の間で接続が構築され、メモリは、第１ノード(16)、第２ノード(18)及び第３ノード(22)のアドレスを格納する。第１ネットワーク(12)はＥｔｈｅｒｎｅｔネットワークが好ましく、第２ネットワークはＡＴＭネットワークが好ましい。ゲートウエイ(24)はＰＣ(パーソナルコンピュータ)が望ましい。望ましくは、第１ノード(16)及び第３ノード(22)はＡＴＭネットワークの一部であり、第１ノード(16)、第３ノード(22)及びゲートウエイ(24)は、ＡＴＭネットワークを通じて、パケットを互いにマルチキャストする。
【００１３】
本発明は、遠隔通信コールを生成する方法に関する。本発明の方法は、第１ネットワーク(12)のオーディオストリーム及びビデオストリームを有する第１ノード(16)から、第２ネットワークのオーディオストリーム及びビデオストリームを有する第２ノード(18)をコールするステップを有している。第１ノード(16)と第２ノード(18)の間で、それらのオーディオストリーム及びビデオストリームの通信が互いに行われるように、第１ノード(16)と第２ノード(18)の間でコールを生成するステップがある。
【００１４】
望ましくは、第１ネットワーク(12)のオーディオストリーム及びビデオストリームを有する第３ノード(22)を前記コールに追加し、第１ノード(16)、第２ノード(18)及び第３ノード(22)の間で、それらのオーディオストリーム及びビデオストリームの通信が互いに行なわれるようになし、第１ノード(16)、第２ノード(18)及び第３ノード(22)の間で会議を行なうステップがある。第３ノード(22)を追加するステップは、会議を主催する(host)ためのホストノード(26)と通信するステップを含むことが望ましい。望ましくは、生成ステップは、第１ノード(16)とゲートウエイ(24)の間でコールの第１接続を終了し、ゲートウエイ(24)と第２ノード(18)の間でコールの第２接続を構築するステップを含んでおり、第１接続のデータは、ゲートウエイ(24)から第２ノード(18)へ送られる。ゲートウエイ(24)及びオーディオミキサー(28)を通じて、第２ノード(18)と、オーディオストリームだけを有する第４ノードとの間で通信を行なうステップを有することが望ましい。
【００１５】
ビデオストリーム及びオーディオストリームを有するノードに関するシステム及び方法は、Ｖｉｐｒｓとしても知られており、米国特許出願第１０／１１４４０２号の優先権を主張したＰＣＴ特許出願第ＰＣＴ／ＩＢ０３／０１４６８号に記載されており、その引用を以て本願への記載加入とする。
【００１６】
ゲートウエイ(24)は、Ｅｔｈｅｒｎｅｔのネットワークインターフェースカード(ＮＩＣ)及びＡＴＭ  ＮＩＣを内蔵した標準のＰＣが望ましい。少なくとも１つのＮＩＣがあり、例えば異なる２種類のＥｔｈｅｒｎｅｔは前記ＮＩＣを通じて通信が行われる。望ましくは、２以上のＮＩＣｓがあり、所望により、ＮＩＣｓは、３以上の個別ネットワーク間で通信を行なうことができるような数が望ましい。
【００１７】
ゲートウエイ(24)は、翻訳(translation)と再送信(retransmission)を実行するソフトウエア用のメモリを有している。メモリの一部として、再送信されるべきビデオストリーム及びオーディオストリームを保有するバッファがある。また、ゲートウエイ(24)が所定時刻に異なる接続を実行する際、異なる接続に対して異なるアドレス情報が格納される。
【００１８】
本発明の動作を説明すると、第１ネットワーク(12)のオーディオストリーミング能力及びビデオストリーミング能力を有するソースノードは、第１ネットワーク(12)とは異なる第２ネットワーク(14)のオーディオストリーミング能力及びビデオストリーミング能力を有するソースノードと通信を行なう。例えば、ＡＴＭネットワークのオーディオストリーミング能力及びビデオストリーミング能力を有する第１ノード(16)と、Ｅｔｈｅｒｎｅｔのオーディオストリーム能力及びビデオストリーミング能力を有する第２ノード(18)との２地点間(point-to-point)のビデオコールの場合、第１ノード(16)は、最初に、インバイト信号(invite signal)をＡＴＭネットワークのサーバへ送信する。インバイト信号は、その中に第２ノード(18)のアドレス又はネームを有しており、サーバに対してコールの送信先を特定するために用いられる。サーバは、インバイト信号を受信し、サーバ内に格納されたルーティング規則(routing rules)を適用してインバイト信号の経路を定める。インバイト信号は標準のＳＩＰプロトコルに従う。ルーティング規則に基づいて、サーバは、インバイト信号内のアドレスを確認し、インバイト信号内のネームと関連のあるアドレスを見つけた後、送信先がＥｔｈｅｒｎｅｔの第２ノード(18)であること、及び前記接続内の第２ノード(18)に達することができるように、ゲートウエイ(24)を通過しなければならないことを確認する。サーバは、第２ノード(18)のアドレスと共に、ゲートウエイ(24)へインバイト信号を送る。ゲートウエイ(24)は、インバイト信号を受信し、サーバから受信したインバイト信号から第２ノード(18)のアドレスを引き出して、別のインビテーションを作成し、第２のいわゆる「バックツーバック(back-to-back)」(Ｂ２Ｂ)ＳＩＰコールを生成して、Ｂ２Ｂコールのインバイト信号を第２ノード(18)に送信する。第２ノード(18)へは、インバイト信号と共に、第１ノード(16)のアドレスも送信される。第２ノード(18)は、ゲートウエイ(24)からインバイト信号を受信し、ＯＫ信号に応答してゲートウエイ(24)に戻り、接続を容易にするために、第２ノード(18)に関する情報を運ぶ。また、第１ノード(16)のアドレス情報はインバイト信号の一部であるから、第２ノード(18)は第１ノード(16)のアドレスを知ることができる。第２ノード(18)からのＯＫ信号は、ゲートウエイ(24)が受信する。当初のインカミングコール(incoming call)に対応するＯＫ信号は、第２ノード(18)のオーディオ／ビデオネットワークアドレスを、新たに割り当てられたゲートウエイ(24)アドレスと置き換えることによって作られる。
ＩＮＶＩＴＥは、ＳＩＰヘッダーにおける発信元のユーザ識別体(名前とホストアドレス)とメディア(オーディオ及びビデオ)アドレスを運ぶ。ユーザ識別体はメディアアドレスから分離して運ばれることもある。これらは、メッセージの中のセッション記述パート(Session Description Part；ＳＤＰ)のアタッチメントの中で運ばれる。発信元ユーザ情報(originating user info)は、ゲートウエイ(24)によっては変化しないが、ＳＤＰのメディアアドレスは、ゲートウエイ(24)がＩＮＶＩＴＥ及びＯＫメッセージを転送する(forward)とき、ゲートウエイ(24)アドレスに対してスワップされる(swapped)。各ノードは、ゲートウエイ(24)メディアアドレスが実際には他のノードのメディアアドレスであると考える。
【００１９】
第１ノード(16)は次に、オーディオ及びビデオストリーミングパケットを、当該分野で周知の如く、ユニキャストの方法で、第１接続を通ってゲートウエイ(24)に送信する。ゲートウエイ(24)では、第１接続が終了し、当該分野で周知のように、パケット内のデータが引き出される。ゲートウエイ(24)は、次に、第１接続及びブロードキャストパケットから第２ノード(18)へバッファされたデータを獲得する。このときフォーマットを変える必要がなく、データの混合もない。第１ノード(16)と第２ノード(18)は、ＳＩＰ標準に従って、２種又は３種の異なるオーディオフォーマット及びビデオフォーマットを取り扱うことができる。そのフォーマットの１つは、例えば、第２ノード(18)からＯＫ信号を受信した後、第１ノード(16)によって選択されるからである。
【００２０】
反対に、第２ノード(18)からのオーディオストリームとビデオストリームは、このようにして、ゲートウエイ(24)が仲介(intermediary)として作用し、第１ノード(16)へ送られる。ここで、第２ノード(18)からゲートウエイ(24)までの第２接続は終了し、次に、第２ノード(18)からのデータは、第１接続を通り、ゲートウエイ(24)から第１ノード(16)へ送られる。第１ノード(16)の側からみれば、第２ノード(18)は、ゲートウエイ(24)によって表されるＡＴＭネットワークの一部であり、第２ノード(18)の側からみれば、第１ノード(16)は、ゲートウエイ(24)によって表されるＥｔｈｅｒｎｅｔの一部と考えられる。
【００２１】
会議コール(conference call)の場合、第１ノード(16)は、サーバを通して、インバイト信号を会議のホストノード(26)へ送信する。会議ホストノード(26)は、第１ノード(16)と同じであってもよいし、別個のノードであってもよい。ホストノード(26)へ送られるインバイト信号の中で、会議が行われるべき他のノードが特定される(identified)。ホストノード(26)は、会議用として認識された他のノードへ、サーバを通じて、インバイト信号を送信する。サーバは、(カスタマーに設定されたルールに基づいて)、ノードの１つ(例えば、第２ノード(18))がＡＴＭネットワークの一部であることを検出し、インビテーションの経路をゲートウエイ(24)に振り分ける(route)。ゲートウエイ(24)は、コールのＥｔｈｅｒｎｅｔ側のパーティ(parties)の代わりに、自ら(ゲートウエイ)のネットワークアドレスを、オーディオ及びビデオストリーム情報の中へ挿入し、対応するＢ２Ｂインビテーションを、サーバを通じて第２ノード(18)へ送信する。
【００２２】
第２ノード(18)は、ホストノード(26)へ戻るＫ信号を有するインバイト信号に応答し、自らのオーディオ及びビデオのフォーマット及びネットワークアドレスを、オーディオ及びビデオストリーム情報に挿入する。ＯＫ信号は、ゲートウエイ(24)を経て戻り、第３ノード(22)とのオーディオ及びビデオ接続を構築し、ホストに対応するＯＫメッセージを作成し、第２ノード(18)のメディアアドレスを、新しく割り当てられたゲートウエイ(24)のアドレスと置き換えて、Ｂ２Ｂインバイトメッセージと置換された元のＥｔｈｅｒｎｅｔ側パーティのメディアアドレスと置き換える。ゲートウエイ(24)は、次に、ＯＫ信号を元のホストへ転送する。
【００２３】
ホストノード(26)は、２地点間ノードに関して既に説明したのと同様に、インバイト信号を第３ノード(22)へ送信する。第３ノード(22)からのＯＫ信号により、ホストは、追加のインバイトメッセージ(「re-invite」メッセージと称されることもある)を送信して、最初の２つのノードに対し、第３ノード(22)が会議に参加したことを告知し、第３ノード(22)のメディアアドレスを提供する。このre-invite信号はまた、元のインバイトメッセージについて説明したように、ゲートウエイ(24)を経て、第２ノード(18)へ送られる。これにより、ゲートウエイ(24)には追加の接続が構築され、第２のパーティに対し、第１ノード(16)及び第３ノード(22)の両ノードからのオーディオ及びビデオが供給される。
【００２４】
一旦、ノード間の接続が行われると、同じネットワークの一部である第１ノード(16)と第３ノード(22)は、ゲートウエイ(24)を通じて、パケットを互いに直接送信すると共に、第２ノード(18)にも送信する。ゲートウエイ(24)は、第２ノード(18)が、第１ノード(16)及び第３ノード(22)とは異なるネットワーク上にあり、第１ノード(16)及び第３ノード(22)からメディアデータパケットを受信し、それらパケットを、ゲートウエイ(24)から第２ノード(18)までの接続を通じて再送信する。
【００２５】
また、第２ノード(18)で作成されたデータは、前記とは逆に、第１ノード(16)及び第３ノード(22)へ送られる。ＡＴＭネットワークにおいて、第１ノード(16)、第３ノード(22)及びゲートウエイ(24)は、各々が会議のために維持するマルチキャストツリーに基づいて、パケットを互いにマルチキャストする。
【００２６】
ホストノード(26)は、実際には、マルチキャストパケットを送受信することはない。ＩＰ側では、当該分野で広く知られているように、パケットを理解しようとし、また理解することのできるノードだけを用いて、パケットの通信が行われる。
【００２７】
ホストがＥｔｈｅｒｎｅｔの一部である第４ノードに参加するとき、第２ノード(18)は会議に参加するので、第４ノードは会議に参加する。しかしながら、ゲートウエイ(24)は、第２ノード及び第４ノードの各ノードに対して、別個のクロスコネクト(cross-connects)を維持する。このため、第２ノード(18)と第４ノードが、ゲートウエイ(24)を通じて、ＡＴＭネットワークのノードまで通過する場合、及びその逆の場合でも、ＡＴＭネットワークのノードに関しては、第２ノード(18)と第４ノードは、互いに区別され、各々は独立した接続を有している。
【００２８】
ゲートウエイ(24)は、ネットワーク中の１又は２以上のビデオサーバの存在をサポートすることができる。ビデオサーバは、ビデオストリームとオーディオストリームを作成するだけで、ビデオストリーム又はオーディオストリームを受信しない。ビデオサーバは、ネットワークの他のノードと同じように、ゲートウエイ(24)によって処理される。つまり、ビデオサーバが受信したパケットは、ビデオサーバが内蔵されたネットワークとゲートウエイ(24)が接続されたネットワークとは異なるネットワーク上にある最終の送信先に向けて、処理される。
【００２９】
ビデオサーバと同じネットワーク内のノードに配備されたビデオサーバによって作成されたストリームは、ネットワークの種類に応じて、ＡＴＭ  ＰＭＰ接続又はＩＰマルチキャストを経由して、これらノードへ送られる。このとき、ゲートウエイ(24)が前記ストリームを受信することはない。異なるネットワーク上にあるビデオサーバからストリームを受信すべきノードは、まず最初に、ゲートウエイ(24)が受信する。ここで、ビデオサーバとゲートウエイ(24)との接続は終了し、ゲートウエイ(24)は、そのストリームを、別個のＢ２Ｂ接続を通じて、他のネットワークの最終送信先へ再送信する。本質的に、ビデオサーバは、ビデオ及びオーディオストリームを有する他の全てのノードと同じように処理される。但し、各ノード及びゲートウエイ(24)が、ビデオ及びオーディオストリームをビデオサーバへ戻すことはない。
【００３０】
例えばＰＳＴＮラインのように、オーディオストリームだけを有するノードが、コールの一部として存在する場合、ミキサーを通じて、ビデオ及びオーディオストリームを有するノードはＰＳＴＮラインと通信することができる。そのような場合、ミキサーは、ゲートウエイ(24)を、オーディオストリーム及びビデオストリームを有する単なる別のノードとして認識し、ゲートウエイ(24)からミキサーへ提供される全てのパケットは、オーディオ及びビデオストリームを有する実際のノードからの他の全てのストリームとして処理される。ここでは、オーディオストリームはミキサーで終了し、バッファされ、再フォーマットされた状態で、ＰＳＴＮラインへ再送信される。送信先が他のネットワークのノードであるＰＳＴＮラインからの全てのオーディオストリームは、まず最初に、ミキサーへ送られ、ここで再フォーマットされ、ゲートウエイ(24)へ再送信され、次に、オーディオストリームはＰＳＴＮラインから他のネットワークの送信先ノードへ再送信される。実際には、オーディオストリーム単独であり、オーディオ及びビデオストリームの両ストリームではなく、オーディオ及びビデオストリームを有するノード以外に他の識別能力(distinct capabilities)を有しないという意味で、ノードが異なっていても、オーディオ及びビデオストリームを有するノードである限り、他の同様なノードからストリームを単に受信するだけである。
【００３１】
ＩＭＧＷは、ゲートウエイとしても知られており、該ＩＭＧＷは、ＶｉＰｒと関連づけられたメディアストリームを、ドメイン能力が異なるドメイン間で相互通信させることのできるデバイスである。例えば、ＩＭＧは、ＡＴＭ  ＳＶＣドメインと、ＩＰルートのドメイン(IP Routed domains)との間でブリッジを作成する。ＩＰルートのドメインは、Ｅｔｈｅｒｎｅｔ又はＡＴＭベースであるが、この機能の主たる用途は、ＩＰ／ＥｔｈｅｒｎｅｔストリームをＡＴＭ  ＳＶＣストリームに相互接続(bridging)することにある。この機能では、ＩＰユニキャスト(ＵＣ)は、ＡＴＭ２地点間(Ｐ２Ｐ)ストリームに対してブリッジが作成され、ＩＰマルチキャスト(ＭＣ)ストリームは、ＡＴＭ２地点マルチキャスト(ＰＭＰ)ストリームに対してブリッジが作成される。代表的な構成例を図１に示す。
【００３２】
上記例では、ＩＭＧＷｓは、ＡＴＭ上に位置するＶｉＰｒ端末とＥｔｈｅｒｎｅｔネットワークとの間で、メディアストリームを相互接続するのに用いられる。簡略化のために、コールシグナリング経路とＶｉＰｒサーバは図示していない。
【００３３】
第２の特徴として、ＩＭＧＷは、ＭＣ又はＰＭＰストリームを、複数のＩＰユニキャスト(ＭＵＣ)ストリーム又は複数のＡＴＭ２地点(ＭＰ２Ｐ)ストリームに変換する能力を有することである。この特徴により、メディアストリームは、ＭＣ／ＰＭＰドメインからＵＣ／Ｐ２Ｐドメインへ転送されることが可能となる。ＵＣ／Ｐ２Ｐドメインを完全にトラバースするために、ＩＭＧＷは、ＭＵＣ／ＭＰ２Ｐストリームを再びＭＣ／ＰＭＰへ変換する。この能力を利用して、例えば、ＭＣをサポートしていないＩＰ  ＷＡＮを、ＭＣをサポートするＬＡＮｓへトラバースすることができる。その逆も可能である。
【００３４】
一般的に、ＩＭＧＷは、異なるメディアドメインに属するＳＩＰデバイス間でコールを相互接続する。そうでないと、メディアデータを適切に交換することができない。それは、１つのドメインの１デバイスからのコールを受け入れ、別のドメインの他のデバイスに対応するコールを作成することにより行われる。ＩＭＧＷは、２種類のコールを関連づけて、メディアストリームを一方の側から他方へ転送する。これにより、どちらか一方側でＳＩＰデバイスのＲＴＰリレーとして機能する。インカミングコール及びアウトゴーイングコール(outgoing call)は、「バックツーバック」(Ｂ２Ｂ)と称されることもあり、それゆえ、ＩＭＧＷは、Ｂ２Ｂユーザエージェント(Ｂ２ＢＵＡ)と称されることもある。
【００３５】
コールルーティングは、ＶｉＰｒ  ＳＩＰサーバによって実行される。このとき、ＩＭＧＷを通じてコールの経路をいつ振り分けるかを判断するために一組のルールが適用される。サーバがコールの経路をＩＭＧＷに設定すると、情報はメッセージの中に入れられるので、ＩＭＧＷは、ブリッジ作成のためにＢ２Ｂコールを必要とするアウトゴーイングコール送信先を決定することができる。
【００３６】
ＩＭＧＷは次のコンポーネントに分解することができる。
・バックツーバックユーザエージェント(Ｂ２ＢＵＡ)
・メディアリレー
・ＳＩＰコールハンドラー(Call Handler)
これらのコンポーネントは、図２に示すように相互に作用する。
【００３７】
メディアリレーコンポーネントは、メディアストリームを中継する機能を実行する。メディアリレーコンポーネントは、インカミングメディアデータを受信し、該メディアを、連繋されたアウトゴーイングメディアチャンネル上を中継(再送信)する。
【００３８】
Ｂ２ＢＵＡは、インカミングコールをアウトゴーイング(ブリッジング)コールと照合(match)するために、コール制御ロジックを提供する。構築されたコールについて、インカミングメディアストリームを中継するためのメディアチャンネルをセットアップ又は解除(tear down)できるように、Ｂ２ＢＵＡは、メディアリレーコンポーネントと接続する。
ＳＩＰ  コールハンドラーは、ＳＩＰ機能を実行し、Ｂ２ＢＵＡにインターフェースを提供し、ＳＩＰコールを管理する。
【００３９】
外部通信のために、ＩＭＧＷで用いられる主機構は、ＳＩＰメッセージを介し、ＩＭＧＷと、該ＩＭＧＷに連繋されたＶｉＰｒサーバの間で主として交換される。この相互作用は、フィールド内のメッセージに含まれる追加のルーティング情報以外は、ＶｉＰｒ端末とＶｉＰｒサーバとの間で起こることと実質的に同一である。このルーティング情報は、ＳＩＰメッセージの中で、ＵＲＩエンコーディング又はＸ ｆｏｒｗａｒｄラインを経由する２つの方法で表される。
【００４０】
Ｘ ｆｏｒｗａｒｄラインのルーティングでは、ＶｉＰｒサーバにより、「Ｘ ｆｏｒｗａｒｄ」ラインが、ＩＮＶＩＴＥメッセージのＳＤＰパートへ追加されるもので、前記メッセージには、真に目的とする受信者(recipient)が含まれている。例えば、あるユーザが、ＳＩＰサーバアドレス196.40.34.21のユーザ「ｖｉｐｒ２」へコールを入れるものとし、送信元のＶｉＰｒ端末のＩＰアドレスが169.144.50.222であると、初期ＩＮＶＩＴＥメッセージは次の通りである。
INVITE sip: vipr2@ 196. 40. 34. 21
Via: 169. 144. 50. 222
【００４１】
ＳＩＰサーバは、そのコールのＩＭＧＷへの転送を決定すると、このメッセージを修正する。当初意図された受信者の情報を、Ｘ ｆｏｒｗａｒｄラインに移動させ、そのコールの経路をＩＭＧＷへ振り当てる。
INVITE sip: IMGW@ 169. 144. 50. 111
Via: 169. 144. 34. 21
Via: 169. 144. 50. 222
(SDP)
X forward: vipr2@ 196. 40. 34. 21
【００４２】
ＩＭＧＷがコールを受信すると、当初意図された受信者を、メッセージのＳＤＰパートの「Ｘ ｆｏｒｗａｒｄ」ラインから復活(recover)させ、新たに関連づけられたアウトゴーイングコールを構築し、次のＩＮＶＩＴＥメッセージを元のサーバに送る。
INVITE sip: vipr2@ 196. 40. 34. 21
Via: 169. 144. 50. 111
【００４３】
このメッセージは、ＩＭＧＷから当初意図された受信者に対し、新たな別個のＳＩＰコールを表す。ＩＭＧＷは、当初のインカミングコールと、この新たなアウトゴーイングコールとの関係を維持する。サーバは、ルーティングルール(新たな「Ｖｉａ」情報を調べる)に基づいて、この新たなコールの経路を上記例の送信先へ直接振り分けることができるかどうかを決定する。
【００４４】
ＵＲＩエンコードされたルーティングは、代替となるＶｉＰｒサーバ技術であり、これによって、サーバがＩＭＧＷを通じてコールの経路を振り分けるとき、コールのＩＮＶＩＴＥ  ＳＩＰヘッダーは、ＩＭＧＷへ送られる前に修正される。例えば、送信元のＶｉＰｒ端末のＩＰアドレスが169.144.50.222、ＶｉＰｒサーバのＩＰアドレスが169.144.50.41であると、当初のフォームは次の如く示される。
INVITE sip: vipr2@ 196. 40. 34. 21:1234
Via: 169. 144. 50. 222
【００４５】
コールをＩＭＧＷへ送るフォームの中に書き換えられるが、当初意図された受信者は保存される。上記例において、ＩＭＧＷのＩＰアドレスが169.144.50.111の場合、書き換えられたフォームは次のとおり示される。
INVITE sip: vipr2..viprhost..196. 40. 34. 21..viprport..1234@169. 144. 50. 111
Via: 169. 144. 50. 41
Via: 169. 144. 50. 222
【００４６】
ＩＭＧＷがコールを受信すると、ネームのキーワード「..viprhost..」及び「..viprport..」について情報解析することにより、当初意図された受信者を復活させ、新たに関連づけられたアウトゴーイングコールを構築し、次のＩＮＶＩＴＥメッセージを元のサーバに送る。
INVITE sip: vipr2@ 196. 40. 34. 21:1234
Via: 169. 144. 50. 111
【００４７】
このメッセージは、ＩＭＧＷから当初意図された受信者に対し、新たな別個のＳＩＰコールを表す。ＩＭＧＷは、当初のインカミングコールと、この新たなアウトゴーイングコールとの関係を維持する。サーバは、ルーティングルール(新たな「Ｖｉａ」情報を調べる)を使用し、この新たなコールの経路を上記例の送信先へ直接振り分けることができるかどうかを決定する。
【００４８】
次に実施例を挙げて説明する。
３組のＡＴＭパーティ(各々が単一のメディアストリームを有する)を有する既存の会議コールは、ＩＭＧＷを介して、第４(Ｅｔｈｅｒｎｅｔ)パーティを追加する。それゆえ、インカミングＩＮＶＩＴＥメッセージＳＤＰは、ネットワークアドレスが(97)(98)(99)の３つのストリームを有している。この実施例では、ＩＭＧＷは、ＡＴＭインターフェイスアドレスが(90)であり、Ｅｔｈｅｒｎｅｔインターフェースアドレスが(60)である。
【００４９】
図３は、事象(ＡＴＭ  ＮＳＡＰのハンドリングについては簡略化のために省略している)の下記シーケンスを示しており、中央の垂直線は、Ｂ２Ｂコールの２つのコールレッグ(call legs)間におけるＩＭＧＷ翻訳の境界を表す。
１．インカミングＩＮＶＩＴＥメッセージを受信する。Ｂ２ＢＵＡは新たなアウトゴーイングコールを準備し、遠隔のインカミングストリーム情報を、アウトゴーイングローカルストリームへ複写し、次に、そのストリームアドレスを、ＩＭＧＷＥｔｈｅｒｎｅｔアドレスへ翻訳する。
２．Ｂ２ＢＵＡはＴＩＳストリームを更新し、新たなストリームに対してネットワークポート(及びメディアの「親」チャンネル)を割り当てて、ポート番号を、元のアウトゴーイングコールのローカルストリームへ複写する。エネーブル状態のローカルコールストリームに対してメディアチャンネルが割り当てられ、Ｂ２ＢＵＡは、ＩＮＶＩＴＥを遠隔のパーティへ送信する。
３．遠隔パーティからの応答を受信する。Ｂ２ＢＵＡは、クロスコネクト内の遠隔パーティストリームＩＤをセーブする。以前に割り当てられたメディアチャンネルは、遠隔のコールストリーム(新たなパーティから)で更新される。
４．Ｂ２ＢＵＡは、ＶＨｏｓｔサイドのストリーム情報を翻訳しないが、遠隔パーティストリームを翻訳する。(翻訳された)遠隔パーティストリーム情報は、ＶＨｏｓｔサイドのコールレッグの中にセーブされる。
５．(翻訳された)遠隔パーティストリームをローカル情報として用い、コール遠隔ストリームを遠隔情報として用いて、メディアチャンネルがＶＨｏｓｔサイドに割り当てられる。このようにして割り当てられたチャンネル番号は、コールのローカルストリームの中でセーブされる。
６．コールのローカルストリームは、元のＩＮＶＩＴＥに対するリプライを作成するために用いられる。
【００５０】
どちらのコールレッグの場合も、その後のコールメッセージは、パーティストリーム又はＴＩＳストリームの中で表される対応ストリームを更新し、割当を初期化し、メディアチャンネルをフリーにする。
【００５１】
有効なＯＫメッセージを受信すると、現在のＳＩＰスタックの実行により、ＡＣＫメッセージは自動的に作成される。受信すると、ＡＣＫメッセージにより、ＯＫメッセージの発信者は、その後のｒｅ−ＩＮＶＩＴＥメッセージを送信することができる。Ｂ２Ｂコールの一方側がＯＫメッセージを受信し、該ＯＫ信号が他方のコールレッグへ転送される前に、ＩＭＧＷでは、ＡＣＫが自動的に送信される。これは、コールレッグ間に潜在的な同期化問題をもたらすので、遠隔パーティが元のＯＫに対してＡＣＫを送信できる前に、その後のｒｅ−ＩＮＶＩＴＥが送信され転送される場合は、エラーとなる。Ｂ２ＢＵＡは、新たなＡＣＫ事象と、この問題を防止するための一対の同期化フラグを実行する。ＯＫメッセージが送られる前に、ＡＣＫメッセージを待機することを表示するフラッグが、コールレッグにセットされる。このフラッグにより、その後の全てのｒｅ−ＩＮＶＩＴＥメッセージの転送は阻止される。他のコールレッグでｒｅ−ＩＮＶＩＴＥを受信すると、フォワーディングロジックは、アウトゴーイングコールレッグがＡＣＫフラッグをセットしたことを検出し、待機フラッグ(Pending flag)をセットすることにより、動作を遅らせる。ＡＣＫを受信すると、ＡＣＫ事象ハンドラーは、ＡＣＫフラッグをクリアし、待機フラッグをチェックすることにより、その事象を処理する。待機フラッグがセットされると、ハンドラーは、現在のコールストリームオファリングを転送し、アウトゴーイングコールレッグに対するｒｅ−ＩＮＶＩＴＥの阻止を完了する。
【００５２】
コール委託メッセージ(Call Referral message)は、一般的には、接続されたパーティに送られ、第３パーティにＩＮＶＩＴＥを送信するように方向づけを行ない、現在のコールを廃棄する。Ｂ２ＢＵＡは、ブリッジングされたコールで受信したＲＥＦＥＲメッセージを、関連づけされたＢ２Ｂコールへ単に中継するだけである。全てのＩＮＶＩＴＥメッセージ又はこのトランスアクションによって生ずるＢＹＥメッセージは、通常通り取り扱われる。
【００５３】
ＩＮＶＩＴＥ又はＲＥＦＥＲメッセージは、選択的に、「Ｒｅｐｌａｃｅ」コールＩＤ値を含んでいる。このＩＤ値は、インバイトされたパーティの既存コールのＩＤであり、これは、新たなコールと置き換えられる。新たなインカミングコールを承諾すると、インバイトされたパーティは特定の(「ｒｅｐｌａｃｅｄ」)コールを中止(hang up)し、ＶｉＰｒユーザのインターフェースは、置換されたコールのコール接続を、新たなコールのコール接続と置き換えることによって変更を実行する。メッセージ中に特定された「Ｒｅｐｌａｃｅ」コールと適合するコールがない場合、Ｂ２ＢＵＡは、そのメッセージを転送し、「Ｒｅｐｌａｃｅ」ヘッダーをアウトゴーイングメッセージの中に複写する。もし、ＳＩＰコードが、「Ｒｅｐｌａｃｅ」コールと適合する既存のコールを見つけると、そのコールＩＤを検索し、Ｂ２ＢＵＡに対して、そのコール事象をＲｅｐｌａｃｅコールＩＤとして供給する。
【００５４】
Ｂ２ＢＵＡが、ＲｅｐｌａｃｅコールＩＤを有するインカミングメッセージを受信すると、そのコールを見つけるために、マスターコールレッグリストをスキャンする。関連あるＢ２Ｂコールのメディアを転送する前に、Ｂ２ＢＵＡは、図４のＲＥＦＥＲメッセージで示されるように、「Ｒｅｐｌａｃｅｄ」コールレッグのコールＩＤを、Ｂ２Ｂのカウンターパートと置き換える。
【００５５】
クライアントがビデオサーバチャンネルを見ることを所望する場合、自らのメディアストリームを非アクティブにセットし、有効なネットワークをアドレッシングして、ブロードキャスト型のＩＮＶＩＴＥメッセージを送信する。ビデオサーバは、ＯＫメッセージに反応して、有効なマルチキャストネットワークアドレッシングでブロードキャストされる自らのビデオストリーム及びオーディオストリームを特定する。初期接続の後、ビデオサーバは、クライアントが接続状態にあることを保証するために、周期的にｒｅ−ＩＮＶＩＴＥメッセージを送る。
【００５６】
Ｂ２ＢＵＡは、会議コールと同じ様に、この変換を処理する。接続のビデオサーバ側は、会議コールのＶＨｏｓｔ側と同様である。ＴＩＳストリームは、ビデオサーバの(翻訳された)ストリームを表し、クライアントのコールレッグの遠隔パーティストリームは、クライアントの複写を保有し、サーバのコールレッグの遠隔パーティストリームは、ビデオサーバストリームの複写を有している。各ビデオサーバの接続は、チャンネルネームとビデオサーバのＩＰアドレスから作り出されたＧＵＩＤを有するセッションに属している。このようにして、同じビデオサーバチャンネルを見る複数のクライアントは、同じセッションに属するクロスコネクト(相互接続)を構築する。このようにして、同じ親メディアチャンネルを共有し、同じビデオサーバ出力について、複数の送信を回避することができる。
【００５７】
特定のクライアントについて、サーバのコールレッグメディアチャンネルは、遠隔パーティストリームを、(翻訳された)ストリーム情報として、コールローカルストリームを、(翻訳された)ローカルメディア情報として用いることによって構築される。割り当てられたチャンネル番号は、コールローカルストリームに格納される。クライアント側のコールレッグについては、メディアチャンネルは、クライアントの遠隔パーティストリームを遠隔ストリーム情報として、ビデオサーバからの(翻訳された)ＴＩＳストリームをローカルメディア情報として用いることによって構築される。割り当てられたチャンネル番号は、コールローカルストリームに格納される。
【００５８】
メディアリレーコンポーネントは、メディアデータを中継する機能を実行する。メディアリレーコンポーネントは、インカミングメディアストリームを表すアクティブメディアチャンネルのリストを処理する。各々のインカミングメディアチャンネルは、どの出力メディアチャンネルがデータを中継すべきかを示すリレーチャンネルを有している。メディアリレーコンポーネントの主データの実体(entity)は、アクティブチャンネルリストである。このリストは、どのインカミングメディアチャンネルがインカミングデータに対してポールされるべきかを示す。チャンネル自体は、既存のＶｉＰｒデコーダのチャンネルオブジェクトに相当する。アウトゴーイングチャンネルは、アクティブなインカミングチャンネルの「Ｒｅｌａｙ  Ｃｈａｎｎｅｌ」の割当によるものだけを意味する。アウトゴーイングチャンネルは、既存のＶｉＰｒエンコーダのチャンネルオブジェクトに相当する。メディアリレーコンポーネントのロジックは、リレーパートと、チャンネル管理パートの主たる２つのパートに分けられる。
【００５９】
メディアリレーの処理ループは、アクティブな入力チャンネル群をポールすることによって開始する。データを有する各インカミングメディアチャンネルの場合、リレーチャンネルはアウトゴーイングチャンネルのマッピングを示す。受信したデータは、次に、アウトゴーイングメディアチャンネルに再送信される。ＩＰ／ＵＤＰヘッダーの削除(stripping)と追加(adding)は必要に応じて行われ、ＩＭＧＷのソフトで用いられたＩＰ及びＡＴＭ  ＡＰＩｓによって暗黙に(implicitly)実行される。メディアリレーコンポーネントは、これまで、ＶｉＰｒで用いられていたメディアチャンネル追加・削除機構と同じものを使用する。これには、ユニキャストのオーディオミキサーで用いられたリレーチャンネル表示を用いることが含まれる。主な違いは、ビデオサーバ接続の場合、メディアチャンネルがエネーブル状態であるのは、ビデオサーバから外向きの一方向だけである点である。
【００６０】
図１に示すネットワーク展開のトポロジーにおいて、ＶｉＰｒ端末は、ハイブリッドなＥｔｈｅｒｎｅｔ及びＡＴＭ−ＳＶＣ  ＬＡＮを通るように配置され、互いに会議を行なうことができる。このシナリオは、次のケースを包含する。
＜ａ．Ｅｔｈｅｒｎｅｔ接続されたＶｉＰｒ端末と、ＡＴＭ−ＳＶＣ接続されたＶｉＰｒ端末とが、バックツーバックＬＡＮｓで会議を行なうこと＞
この場合、ＶｉＰｒ  ＳＩＰサーバは、コールインビテーションが別のメディアのＶｉＰｒ端末に向けられ、ＩＭＧＷへリダイレクトすることを確認する。識別手段は、各メディア(例えば、Ｅｔｈｅｒｎｅｔの場合は169.144.10.0-255、ＡＴＭの場合は169.144.11.0-255)に割り当てられたＩＰアドレススペース、又は異なるＵＲＩのサブドメインネーム(例えば、Ｅｔｈｅｒｎｅｔの場合は@eth.marconi.com、ＡＴＭの場合は@atm.marconi.com)であってよい。コールインビテーションを承認すると、ＩＭＧＷは、ＶｉＰｒサーバによって、送信先端末に対するバックツーバックコールインビテーションを開始する。この時に、ＳＩＰサーバは、コールの経路を最終送信先へ振り分ける。送信先のＶｉＰｒ端末がコールを承認すると、ＩＭＧＷとＶｉＰｒ端末との間でベアラチャンネル(bearer channels)が構築され、ＩＭＧＷは、２つの環境間でブリッジ作成を行なう。ＩＭＧＷは、ＩＰ／ＵＤＰのオーディオ及びビデオのベアラチャンネルを、ＡＴＭ  ＬＡＮのＡＴＭ−ＳＶＣｓへ変換する。また、その逆の変換も行なう。
【００６１】
例えば、ＳＶＣベースのネットワークとＩＰ／Ｅｔｈｅｒｎｅｔベースのネットワークの間でブリッジを作成するとき、ＡＴＭ環境とＩＰ／Ｅｔｈｅｒｎｅｔ環境との間でベアラチャンネルをマッピングするのに、ＩＭＧＷは次の方法を用いることができる。
１．ＩＭＧＷは、ＵＤＰソケットを開いて、Ｅｔｈｅｒｎｅｔ側のソースＶｉＰｒ端末へ接続する。
２．ＩＭＧＷは、ＡＴＭ  ＶｉＰｒ端末に対するＰＴＰ又はＰＭＰ  ＳＶＣを作成し、それを、ステップ１で作られたＵＤＰソケットへマッピングする。
３．ＥｔｈｅｒｎｅｔのＶｉＰｒ端末から受信した全てのＲＴＰトラフィックは、そのＩＰ／ＵＤＰヘッダーから除去され、ＡＴＭ  ＳＶＣを通して、ＡＴＭ  ＶｉＰｒ端末へトランスポートするために、ＡＡＬ５  ＰＤＵｓの中でカプセル化される(encapsulated)。
４．バックボーンＳＶＣから受信した全てのＲＴＰトラフィックは、ＡＡＬ５  ＰＤＵヘッダーから除去され、ＩＰ／ＵＤＰパケットの中にカプセル化され、ユニキャスト／マルチキャストソケットを通じて、ＥｔｈｅｒｎｅｔのＶｉＰｒ端末へトランスポートされる。
【００６２】
＜ｂ．ＡＴＭ−ＳＶＣコアによって相互接続された２つの別個のＥｔｈｅｒｎｅｔＬＡＮｓにおいて、Ｅｔｈｅｒｎｅｔ接続されたＶｉＰｒ端末間で会議を行なうこと＞
この場合、ＶｉＰｒ  ＳＩＰサーバは、コールインビテーションが、別のメディアのＶｉＰｒ端末に向けられてＩＭＧＷへリダイレクトすることを確認する。識別手段は、各メディア(例えば、Ｅｔｈｅｒｎｅｔの場合は169.144.10.0-255、ＡＴＭの場合は169.144.11.0-255)に割り当てられたＩＰアドレススペース、又は異なるＵＲＩのサブドメインネーム(例えば、Ｅｔｈｅｒｎｅｔの場合の@eth.marconi.com、ＡＴＭの場合の@atm.marconi.com)であってよい。コールインビテーションを承認すると、ＩＭＧＷは、ＶｉＰｒサーバを通じて、送信先端末に対するバックツーバックコールインビテーションを開始する。再び、ＶｉＰｒ  ＳＩＰサーバは、コールインビテーションが、別のメディアのＶｉＰｒ端末に向けられて送信先ＩＭＧＷへリダイレクトすることを確認する。このＩＭＧＷは、ＶｉＰｒサーバを介して、送信先端末に対し、第２のバックツーバックコールインビテーションを開始する。この時に、ＳＩＰサーバは、コールの経路を最終送信先へ振り分ける。送信先のＶｉＰｒ端末がコールを承認すると、ＩＭＧＷとＶｉＰｒ端末との間でベアラチャンネルが構築され、ＩＭＧＷは、３つの環境間でブリッジを作成する。ＩＭＧＷは、ＩＰ／ＵＤＰのオーディオ及びビデオベアラチャンネルを、ＡＴＭ  ＬＡＮのＡＴＭ−ＳＶＣｓへ変換する。また、その逆の変換も行う。
【００６３】
例えば、ＡＴＭ−ＳＶＣコアで相互接続されたＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒネットワーク間でブリッジを作成するとき、ＡＴＭ環境とＩＰ／Ｅｔｈｅｒｎｅｔ環境との間でベアラチャンネルをマッピングするのに、ＩＭＧＷは次の方法を用いることができる。
１．ソースＩＭＧＷは、ユニキャスト又はマルチキャストＵＤＰソケットを開いて、Ｅｔｈｅｒｎｅｔ側のソースＶｉＰｒ端末へ接続する。
２．ソースＩＭＧＷは、送信先ＩＭＧＷに対するＰＴＰ  ＳＶＣを作成し、それを、ステップ１で作られたＵＤＰソケットへマッピングする。
３．送信先ＩＭＧＷは、ユニキャスト又はマルチキャストＵＤＰソケットを開いて、Ｅｔｈｅｒｎｅｔの送信先ＶｉＰｒ端末へ接続する。
４．ＩＭＧＷが、ＥｔｈｅｒｎｅｔのＶｉＰｒ端末から任意のＲＴＰトラフィックを受信すると、ＩＭＧＷは、そのＩＰ／ＵＤＰヘッダーから前記トラフィックを除去し、ＡＴＭ  ＳＶＣを通して、送信先ＩＭＧＷへトランスポートするために、ＡＡＬ５  ＰＤＵｓの中にカプセル化する。
５．ＩＭＧＷが、ＳＶＣを通じて、他のＩＭＧＷから任意のＲＴＰトラフィックを受信すると、ＩＭＧＷは、ＡＡＬ５  ＰＤＵヘッダーから前記トラフィックを除去し、ＩＰ／ＵＤＰパケットの中にカプセル化して、ユニキャスト／マルチキャストソケットを通じて、送信先のＥｔｈｅｒｎｅｔのＶｉＰｒ端末へトランスポートする。
【００６４】
図５に示されるネットワーク展開のシナリオでは、ＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒアイランド(islands)は、コーポレイト(corporate)ＡＴＭバックボーンを通じて、互いに会議を行なうことができる。ＩＭＧＷに関しては、前述のシナリオｂと同様である。この環境では、前提として、次の点について留意されるべきである。
ａ．ＡＴＭバックボーンは、ＳＶＣｓをサポートするか、又はＳＶＣｓをセットアップすることができる末端相互(end-to-end)ＰＶＰから構成される。
ｂ．エッジＡＴＭスイッチは、同じピアグループに属するか、又は２つの別個のピアグループ(例えばＡＩＮＩのように静的なもの又はＰＮＮＩのように動的なもの)に属することができる。
【００６５】
図６に示すネットワーク展開のシナリオでは、遠隔サイト(ＳＯＨＯ)のＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒは、サービスプロバイダーのＡＴＭバックボーンを通じて、コーポレイトＨＱと会議を行なうことができ、ＩＰ／ＵＤＰ  ＳＩＰシグナリングをトランスポートするのに、別個のＩＰネットワークを必要としない。ＳＩＰは司令部(headquarters)にある。メディアストリーム(即ち、オーディオ及びビデオストリーム)をルーティングすることに加えて、ＩＭＧＷは、同じＡＴＭリンクを通じて、ＩＰシグナリングチャンネルを、ＶｉＰｒ  ＳＩＰサーバへも転送する。それゆえ、サービスプロバイダーは、遠隔サイトに、１つのＡＴＭ回路を配備するだけで、ＩＭＧＷへ直接接続される。遠隔サイトには、ＡＴＭスイッチは必要でない。
【００６６】
図７に示すネットワーク展開のシナリオにおいて、ＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒ端末は、サービスプロバイダーのＡＴＭバックボーンを通じて、会議を行なうことができ、ＩＰ／ＵＤＰ  ＳＩＰシグナリングをトランスポートするのに別個のＩＰネットワークを必要としない。ＳＩＰサーバは、サービスプロバイダーのスペース内にある。メディアストリーム(即ち、オーディオ及びビデオストリーム)をルーティングすることに加えて、ＩＭＧＷは、同じＡＴＭリンクを通じて、ＩＰシグナリングチャンネルを、ＶｉＰｒ  ＳＩＰサーバへも転送する。それゆえ、サービスプロバイダーは、遠隔サイトに、１つのＡＴＭ回路を配備するだけで、ＩＭＧＷへ直接接続される。遠隔サイトには、ＡＴＭスイッチは必要でない。
【００６７】
図８に示されるネットワーク展開のシナリオでは、マルチキャストをサポートするＩＰ／ＥｔｈｅｒｎｅｔベースのＶｉＰｒアイランドは、マルチキャストをサポートしないサービスプロバイダーのＩＰバックボーンを通じて、互いに会議を行なうことができる。このシナリオでは、マルチキャストのカスタマー環境とユニキャストのサービスプロバイダースペースの間でブリッジを作成するために、サービスプロバイダーサイト及びカスタマーに、ＩＭＧＷｓをインストールする必要がある。なお、ここでは、各ＩＭＧＷは、自らのサイトのＶｉＰｒ  ＳＩＰサーバによって制御されるものとする。コールインビテーションを受信すると、コーポレイトＶｉＰｒ  ＳＩＰサーバは、コールが、ＳＰバックボーンを通じて別のドメインのＶｉＰｒ端末に向けられことを確認する。そのコールは、次に、ＩＭＧＷへリダイレクトされる。識別手段は、ドメイン(例えば、169.144.10.0-255)に割り当てられたＩＰアドレススペース、又は異なるＵＲＩのサブドメインネーム(例えば、@pittsburgh.marconi.com)であってよい。コールインビテーションを受信すると、ＩＭＧＷは、コーポレイトＶｉＰｒサーバによって、送信先端末に対するバックツーバックコールインビテーションを開始する。再び、コーポレイトＶｉＰｒ  ＳＩＰサーバは、コールインビテーションが、ＳＰバックボーンを通る他のドメインのＶｉＰｒ端末に向けられ、ＳＰ  ＩＭＧＷへリダイレクトすることを確認する。このＩＭＧＷは、ＳＰ  ＶｉＰｒサーバによって、送信先端末に対して、第２のバックツーバックコールインビテーションを開始する。
【００６８】
コールインビテーションを受信すると、ＳＰ  ＶｉＰｒ  ＳＩＰサーバは、送信先のコーポレイトＩＭＧＷを確認し、そのコールを該ＩＭＧＷへリダイレクトする。後者は、ローカルコーポレイトＶｉＰｒサーバによって、送信先ＶｉＰｒ端末へのバックツーバックコールのうち最後のコールを開始する。この時に、ＳＩＰサーバは、コールの経路を最終送信先へ振り分ける。送信先のＶｉＰｒ端末がコールを承認すると、ＩＭＧＷｓとＶｉＰｒ端末との間でベアラチャンネルが構築され、ＩＭＧＷは、３つの環境間でブリッジを作成する。ソースカスタマーサイト及びＩＭＧＷは、ＩＰ／Ｅｔｈｅｒｎｅｔのマルチキャストオーディオ及びビデオベアラチャンネルを、ユニキャストストリームへ変換し、それらをＳＰのＩＭＧＷへ転送する。後者は、ユニキャストストリームを、各々が参加サイトのＩＭＧＷへ向けられたマルチ−ユニキャストのストリームに変換する。送信先カスタマーサイトのＩＭＧＷｓは、ＩＰ／Ｅｔｈｅｒｎｅｔのユニキャストのオーディオ及びビデオベアラチャンネルを、マルチキャストストリームに変換し、それらを参加ＶｉＰｒ端末に転送する。図９はＩＰ  ＬＡＮとＡＴＭ  ＷＡＮの関係を示している。
【００６９】
ＶｉＰｒは、マルチストリームのマルチメディアセッションを構築し、修正し、削除する手段として、セッション開始プロトコル(Session Initiation Protocol; ＳＩＰ)を使用する。ＶｉＰｒ  ＩＭＧＷは、異種のネットワーク環境において、相互運用性(interoeprability)を提供する。ＶｉＰｒ  ＩＭＧＷｓは、標準の演算プラットフォームで動作するソフトウエアのゲートウエイであり、単一又は複数の構成として配置することができる。
【００７０】
本発明の実施例について詳細に説明したが、それらは単なる例示であって、当該分野の専門家であれば、特許請求の範囲に記載された発明の精神及び範囲から逸脱することなく、その詳細について変形を成し得ることは理解されるべきである。
【図面の簡単な説明】
【００７１】
【図１】本発明の遠隔通信システムの略図である。
【図２】本発明のＩＭＧＷコンポーネントの概要のブロック図である。
【図３】第１ネットワークと第２ネットワークとの会議コールのブロック図である。
【図４】関連づけられたＢ２Ｂコールにメッセージを転送する前に、Ｂ２ＢＵＡが置換されたコールレッグのコールＩＤを、そのＢ２Ｂカウンターパートと取り替えることを示すブロック図である。
【図５】ＡＴＭ  ＳＶＣ(ＷＡＮ)へ通じるＥｔｈｅｒｎｅｔの略説明図である。
【図６】ＩＭＧＷを通して行われるＡＴＭコーポレイトＷＡＮの略説明図である。
【図７】ＩＭＧＷを通して行われるＡＴＭ  ＳＰ  ＷＡＮの略説明図である。
【図８】ユニキャスト／Ｐ２Ｐ  ＷＡＮへ通じるマルチキャスト／ＰＭＰの略説明図である。
【図９】ＡＴＭ  ＷＡＮへ通じるＩＰ  ＬＡＮの略説明図である。
【符号の説明】
【００７２】
(10)  システム
(12)  第１ネットワーク
(14)  第２ネットワーク
(16)  第１ノード
(18)  第２ノード
(22)  第３ノード
(24)  ゲートウエイ
(26)  ホストノード
【図１】
2005039803.tif 000003
【図２】
2005039803.tif 000004
【図３】
2005039803.tif 000005
【図４】
2005039803.tif 000006
【図５】
2005039803.tif 000007
【図６】
2005039803.tif 000008
【図７】
2005039803.tif 000009
【図８】
2005039803.tif 000010
【図９】
2005039803.tif 000011