JP2005530454A - 複数参加者通信セッションにおける話者アービトレーションの方法および装置 - Google Patents

Abstract

通信システム（１００）は、データパケットヘッダ拡張子に埋め込まれた話者アービトレーションコマンドを含むＲＴＰフロア管理メッセージ（３００）の使用によって、複数参加者（１１１−１１４）通信セッションにおけるインバンド話者アービトレーションを提供する。

Description

本発明は、一般にインターネットプロトコル（ＩＰ）ネットワークに関し、特に複数参加者ＩＰネットワーク通信セッションにおける話者アービトレーション（調停）に関する。

無線通信システムは公知の技術である。従来の無線通信システムでは、通常、回線切り替えインフラストラクチュアを少なくとも１つの専用無線リソースと組み合わせて使用して、リアルタイムサービスが行われている。しかし、通信産業における現在の傾向は、無線通信をサポートするパケット交換インフラストラクチュアの使用にある。データおよび音声を送信するために、例えば、いわゆる２．５世代の無線技術は、無線装置によるインターネットへの膨大なアクセスを提供している。パケット交換インフラストラクチュアを利用する通信システムでは、インターネットプロトコル（ＩＰ）が音声およびデータ通信の標準になってきている。

ボイスオーバインターネットプロトコル（ＶｏＩＰ）通信セッションでは、一般に、その（通信）セッションのセットアップに含まれるメッセージングが、セッション開始プロトコル（ＳＩＰ）を用いてセッションをセットアップし、リアルタイムプロトコル（ＲＴＰ）を用いてセッション参加者間の音声データパケットのリアルタイム交換を行っている。ＳＩＰは、複数の異なったトランスポート層プロトコル上で実行可能なアプリケーション層信号プロトコルであって、１人または２人以上の参加者が参加するセッションを起動、変更、終了するのに用いられる。ＳＩＰは、プロシキサーバ、登録係、およびアプリケーションと会議サーバを使用して、セッション参加者に登録機能を提供し、参加者の要求を特定して経路指定を行い、参加者に対するサービスを認証して許可し、参加者に（通信セッション）機能を提供する。

セッションの起動に使用されるＳＩＰメッセージは、通常、セッションの参加者をボコーダ（ｖｏｃｏｄｅｒ）のような１群の互換性のあるメディア形態に適合させるとともに、ＩＰアドレスおよびポートのような情報の交換を可能にするセッション記述情報を含む。このような（セッション記述）情報は、通常、セッション記述プロトコル（ＳＤＰ）のような種々のプロトコルに準拠してフォーマットされる。ＳＤＰは、関連する呼設定情報を呼の参加者に送信するように設計されていて、セッション通知、セッション招待、およびマルチメディアセッション開始の他の形態のマルチメディアセッションを記述するように意図されている。

通常、半二重通信セッションであるディスパッチ通信セッション、および電話会議のような複数参加者通信セッションは、セッション中任意の特定の時間に誰が話してよいかを調停する厳格な手段を必要とする。この話者アービトレーションプロトコル（ｓｐｅａｋｅｒ ａｒｂｉｔｒａｔｉｏｎ ｐｒｏｔｏｃｏｌ）は、「フロア管理」と呼ばれている。ＳＩＰは、他のある会議管理プロトコルによって管理されるセッションを起動するためにのみＳＩＰが使用されるといったようなサービスは提供しない。一旦セッションが確立されると、ＳＩＰは音声および他のデータの交換を行わない。データパケットは、ＲＴＰを利用してＶｏＩＰセッションの参加者間で共通して交換されるが、ＲＴＰを利用した、フロア管理を提供する規定された機構はまだ存在していない。しかし、話者アービトレー
ションは、ディスパッチまたは電話会議の呼出中に頻繁に発生する可能性があり、そのため話者アービトレーションは、速やかに最低限の遅延で処理される必要がある。したがって、複数参加者ＩＰベース通信セッションに高速フロア管理を提供する方法および装置の必要性が存在する。

複数参加者ＩＰベース通信セッションに高速フロア管理を提供する方法およびその装置の必要性に対処するために、通信システムは、データパケットヘッダ拡張子に埋め込まれた話者アービトレーションコマンドを含むＲＴＰフロア管理メッセージを使用することによって、複数参加者通信セッションにおけるインバンド（帯域内）話者アービトレーションを提供する。

一般に、本発明の実施態様は、複数の参加者を含む通信セッションにおける話者アービトレーションを提供する方法を包含する。この方法は、リアルタイムプロトコル（ＲＴＰ）データパケットを組み立てるステップと、リアルタイムプロトコルデータパケットにヘッダ拡張子を加えるステップと、ヘッダ拡張子に話者アービトレーションコマンドを埋め込んでＲＴＰフロア管理メッセージを生成するステップとを含む。

本発明の他の実施態様は、複数の参加者を含む通信セッションにおける話者アービトレーションの方法を包含する。この方法は、通信セッションのフロアを確保する要求を受理するステップと、フロアを確保する要求を含むリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを組み立てるステップと、ＲＴＰフロア管理メッセージを送信するステップとを含む。

さらに、本発明の他の実施態様は、複数の参加者と、複数の参加者に関連した複数のノードとを含む通信セッションにおける話者アービトレーションの方法を包含する。この方法は、通信セッションにおける複数の参加者の中の１人の参加者から、通信セッションのフロアを確保する要求を含む第１のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを受理するステップと、フロアが利用可能かどうかを判断するステップとを含む。この方法は、フロアが利用可能な場合、フロアを確保する要求を許可する第２のＲＴＰフロア管理メッセージを送信するステップと、フロアが利用可能でない場合、フロアを確保する要求を許可しない第３のＲＴＰフロア管理メッセージを送信するステップとをさらに含む。

さらに、本発明の他の実施態様は、複数の参加者と、複数の参加者に関連した複数のノードとを含む通信セッションのフロア管理を提供する装置を包含する。この装置は、リアルタイムプロトコル（ＲＴＰ）データパケットを組み立て、ＲＴＰデータパケットにヘッダ拡張子を加え、ヘッダ拡張子に話者アービトレーションコマンドを埋め込んでＲＴＰフロア管理メッセージを生成する信号処理装置を備えるゲートウェイを含む。

図１−図５を参照して本発明をより詳細に説明する。図１は、本発明の実施形態による無線通信システム１００のブロック図である。通信システム１００は、インターネットプロトコル（ＩＰ）ネットワーク１０６と各々通信する複数のシステムノード１０１−１０４（４つを示す）を含む。本発明の一実施形態において、無線の実施形態である各ノードは、実質的に１つまたは２つ以上のカバレージエリア内の無線の送受信に対する役割を果たすインフラストラクチュア装置の論理的な表現である。この無線の実施形態において、各ノードは、１つまたは２つ以上の無線基地局システム（ＢＴＳ）に接続された基地局制御装置（ＢＳＣ）を有している。各ノード１０１−１０４は、無線ネットワーク制御装置を有する無線ネットワークサブシステム（図示されない）を介して、ＩＰネットワーク１
０６に接続されている。ノード１０１−１０４の各々は、ノードによってサービスされるカバレージエリアに設置された携帯電話、無線電話、または無線モデムのような移動局（ＭＳ）を初めとするそれぞれの無線ユーザ通信装置１１１−１１４に通信サービスを提供している。そして次に、各通信装置１１１−１１４は、この装置の対応するノード１０１−１０４を介して、ＩＰネットワーク１０６と通信している。

本発明の他の実施形態において、１つまたは２つ以上のノード１０１−１０４は、ボイスオーバＩＰ（ＶｏＩＰ）電話のような対応するユーザ通信装置１１１−１１４に、またはディジタルモデムのようなデータ通信装置（ＤＣＤ）に情報サービスを提供する、プロシキサーバであってもよい。ＤＣＤは、パーソナルコンピュータ、ワークステーション、ラップトップコンピュータ、または他のデータ端末のようなディジタル端末装置（ＤＴＥ）に接続され、ＤＴＥとＩＰネットワーク１０６間でデータを送信するのが好ましい。

各通信装置１１１−１１４は、１つまたは２つ以上のマイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）、それらの組み合わせ、または当業者に知られているような他の装置のような信号処理装置１１６と、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、および／または読み取り専用メモリ（ＲＯＭ）、またはそれらの等価物のような１つまたは２つ以上の記憶装置（図示されない）とを含む。記憶装置は、信号処理装置１１６によって実行されるプログラムおよび信号処理装置１１６によって利用されるデータを格納し、通信システム１００の対応する通信装置が機能できるようにしている。

ＩＰネットワーク１０６は、メディアゲートウエイ制御装置１３０に接続されて動作するメディアゲートウエイ１２０を有している。メディアゲートウエイ１２０は、複数参加者通信セッションに含まれる、ノード１０１−１０４のような複数のノードの各々に共通のＩＰ通信リンクを提供している。本発明の一実施形態において、メディアゲートウエイ１２０は、イリノイ州シャンバーグ（Ｓｃｈａｕｍｂｕｒｇ、Ｉｌｌｉｎｏｉｓ）のモトローラ社（Ｍｏｔｏｒｏｌａ Ｉｎｃ．）から入手可能で、本発明の機能を行なうように修正されているインテリジェントパケットデュプリケータ（ＩＰＤ）である。本発明の他の実施形態において、メディアゲートウエイ１２０は、複数参加者通信セッションに含まれる複数のノードの各々に共通のディジタル通信リンクを提供するパケットデータルータと通信する会議ブリッジを有していてもよい。メディアゲートウエイ１２０は、パケット複製機能を提供する、会議ブリッジに接続されたパケットデュプリケータをさらに含む。

メディアゲートウエイ１２０が、ノード１０１のような複数参加者通信セッションに含まれるノードからデータパケットを受信すると、そのデータパケットを複数参加者通信セッションの通信装置１１２−１１４のような他の参加者に送信するために、メディアゲートウエイは受信データパケットの１つまたは２つ以上の複写を作成する。次に、メディアゲートウエイ１２０は、複写されたデータパケットを他の参加者に対応するノードすなわちノード１０２−１０４に送る。本発明の他の実施形態である「ＩＰマルチキャスト」実施形態において、メディアゲートウエイ１２０は、公知のＩＰマルチキャストの方法を使用してＲＴＰパケットを複製し、パケットを通信装置１１１−１１４の各々に送ることができる。ＩＰマルチキャストの実施形態では、共通のＩＰマルチキャストアドレスが、ノード１０１−１０４の各々または代わりに通信装置１１１−１１４の各々に割り当てられる。通信装置１１１−１１４のいずれかのＳＰＵ１１６によって、共通のＩＰマルチキャストアドレスを含むオーディオパケットをメディアゲートウエイ１２０からユニキャスト形式で調達できる。すると、メディアゲートウエイ１２０のようなＩＰルータで構成されたゲートウェイは、必要な複製をすべて経済的に行なうことができる。

本発明のさらに他の実施形態において、メディアゲートウエイ１２０が、ノード１０１
のような第１のノードから受信したデータパケットをノード１０３のような他のノードに送る場合には、メディアゲートウエイは、パケットを複写する代わりに、恐らくデータパケット宛先に関するヘッダを変更し、かつどんな話者アービトレーションサービスも明示的に提供しないで、受信したデータパケットを単に送ることができる。本発明のさらに他の実施形態では、メディアゲートウエイ１２０によって行なわれるものとしてここで説明する話者アービトレーションサービスは、再び、メディアゲートウエイが受信したデータパケットを単に送ることだけを認可し、かつ恐らくデータパケット宛先に関するヘッダの変更を除きどんな話者アービトレーションサービスも明示的に提供しないで、参加通信装置１１１−１１４またはノード１０１−１０４の中の１つによって代わりに行うことができる。

メディアゲートウエイ１２０は、１つまたは２つ以上のマイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）、それらの組み合わせ、または当業者に知られているような他の装置のような信号処理装置１２４と、信号処理装置１２４が実行できるデータおよびプログラムを格納するランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、および／または読み取り専用メモリ（ＲＯＭ）、またはそれらの等価物のような１つまたは２つ以上の記憶装置（図示されない）とを含む。１つまたは２つ以上の記憶装置によって格納されるデータとしては、複数のゲートウエイルーティングアドレスがあるが、メディアゲートウエイに関連したＩＰアドレスおよびポート番号があるのが好ましい。複数のゲートウエイルーティングアドレスは、通信装置１１１−１１４がデータパケットをメディアゲートウエイに送ることができる複数のルーティング宛先を提供する。通信セッションが確立されると、メディアゲートウエイ１２０は、メディアゲートウエイ制御装置１３０によってノードに割り当てられたメディアゲートウエイＩＰアドレス／ポートの組み合わせを介して、セッションに含まれる複数のノードの各々と通信する。

メディアゲートウエイ制御装置１３０は、通信セッションに対するメディアゲートウエイ１２０の複数のＩＰアドレス／ポートの組み合わせの割り当ておよび橋渡しを管理する。本発明の一実施形態において、メディアゲートウエイ制御装置１３０は、本発明の機能を行なうように修正されている、モトローラ社から入手可能なディスパッチアプリケーションプロセッサ（ＤＡＰ）のようなディスパッチ通信制御装置であってもよい。メディアゲートウエイ１２０が会議ブリッジを備えることができる本発明の他の実施形態では、メディアゲートウエイ制御装置１３０は、本発明の機能を行なうように修正された会議ブリッジ制御装置でもよい。メディアゲートウエイ制御装置１３０は、１つまたは２つ以上のマイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）、それらの組み合わせ、または当業者に知られているような他の装置のような信号処理装置１３２と、信号処理装置１３２が実行できるデータおよびプログラムを格納するランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、および／または読み取り専用メモリ（ＲＯＭ）、またはそれらの等価物のような１つまたは２つ以上の記憶装置（図示されない）とを含む。

通信システム１００はパケットデータ通信システムを備えている。システム１００の通信装置１１１のような通信装置が、通信装置１１２−１１４のようなシステム１００の１つまたは２つ以上の他の通信装置との通信セッションをセットアップするために、それらの通信装置は、自身の対応するノード１０１−１０４を介して、セッション開始プロトコル（ＳＩＰ）メッセージの交換に携わる。ＳＩＰメッセージの交換による通信セッションのセットアップは当業界では公知であり、ＩＥＴＦ（インターネット技術特別調査委員会（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ））によって発行されたＲＦＣ（コメントに対する要請（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ））２５４３に詳細に記述されており、このＲＦＣ２５４３はその全体が引用により本明細書
に組み込まれる。通信セッションが確立されると、音声データは、リアルタイムプロトコル（ＲＴＰ）に準じてフォーマットされたデータパケットによって交換される。ＲＴＰはよく知られているプロトコルであり、ＩＥＴＦによって発行されたＲＦＣ１８８９に記述されていて、ＲＦＣ１８８９はその全体が引用により本明細書に組み込まれる。

各ＳＩＰメッセージはヘッダとメッセージ本文とを有し、メッセージを受信するノードまたは通信装置上で特定の方法すなわち機能を実行する要求を含む。ヘッダは、メッセージのソース、例えば通信装置１１１に関連するルーティングアドレスと、メッセージの１つまたは２つ以上の目的とする宛先、例えば通信装置１１２−１１４に関連するルーティングアドレスとを含む。各ルーティングアドレスは、通常ホスト名と、通信装置を識別するドメインとを含むＳＩＰのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）である。ルーティングアドレスは、ターゲットになる複数参加者のトークグループも識別できる。例えば、ＳＩＰのような発呼起動プロトコルを使用する複数パーティのトークグループのメンバーへのルーティングメッセージの方法は、「発呼起動プロトコルに従って定義されたグループの改善された使用および管理（Ｉｍｐｒｏｖｅｄ Ｕｓｅ
ａｎｄ Ｍａｎａｇｅｍｅｎｔ ｏｆ Ｇｒｏｕｐｓ Ｄｅｆｉｎｅｄ Ａｃｃｏｒｄｉｎｇ ｔｏ ａ Ｃａｌｌ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）」と題する米国特許出願番号第０９／９９０，９２９号に記述されており、この特許出願は本発明の譲受人に譲渡されその全体が引用により本明細書に組み込まれる。

ＳＩＰメッセージのメッセージ本文は、セッションの参加者を１群の互換性のあるセッション詳細に適合可能にするメディア、ボコーダ、サンプリングレートの形態等のようなセッションの記述を含む。ただし、セッション記述情報はＳＩＰを使用して記述されない。もっと正確に言えば、各ＳＩＰメッセージのメッセージ本文は、異なるプロトコルフォーマットに符号化されるが、ＩＥＴＦによって発行されたＲＦＣ２３２７に記述されているようにセッション記述プロトコル（ＳＤＰ）に符号化されるのが好ましく、ＲＦＣ２３２７はその全体が引用により本明細書に組み込まれる。ＳＤＰは、適切な通信セッションセットアップ情報をセッション参加者に送信するように設計されていて、セッション通知、セッション招待、およびマルチメディアセッション開始の他の形態のマルチメディアセッションを記述するように意図されている。

通信システム１００において、通信装置１１１のような開始通信装置がＳＩＰ＿ＩＮＶＩＴＥメッセージをＩＰネットワーク１０６に送ると、複数参加者による通信セッションが開始される。ＳＩＰ＿ＩＮＶＩＴＥメッセージは、通信装置１１１がグループ呼出または電話会議のような少なくとも２つの通信装置を含む複数参加者通信セッションのセットアップを要望していることをＩＰネットワーク１０６に通知する。ＩＰネットワーク１０６は、ＳＩＰ＿ＩＮＶＩＴＥメッセージをメディアゲートウエイ制御装置１３０に送り、制御装置１３０は、通信装置１１１が複数参加者通信セッションのセットアップを要望していることを確認して、通信セッションへの予定参加者をさらに特定する。

本発明の一実施形態において、ＳＩＰ＿ＩＮＶＩＴＥメッセージのＳＤＰは、通信装置１１１を含むトークグループに対応付けられたグループ識別子を含んでいてもよい。メディアゲートウエイ制御装置１３０に存在するまたは接続されたデータベース１３４は、グループ識別子を格納し、トークグループのメンバーである通信装置のリストをさらに格納する。例えば、データベース１３４は、通信装置に各々一意的に対応付けられ、グループ識別子にさらに対応付けられた識別子のリストを格納できる。メディアゲートウエイ制御装置１３０に接続されたロケーションレジスタ１４０は、通信装置にサービス提供するノードのような各通信装置１１１−１１４に関する通信システム１００内での位置を格納する。本発明の他の実施形態では、ＳＩＰ＿ＩＮＶＩＴＥメッセージのＳＤＰは、事前に予定された電話会議に関連したコード名を含んでいてもよい。コード名は、電話会議への参
加が予定されている通信装置のリストにさらに関連づけられていて、そのコード名および対応するリストは、メディアゲートウエイ制御装置１３０に格納される。本発明のさらに他の実施形態では、ＳＩＰ＿ＩＮＶＩＴＥメッセージのＳＤＰは、開始通信装置がセッションへの参加を招待している通信装置に関連した通信装置の識別子のリストを含んでいてもよい。

ＳＩＰ＿ＩＮＶＩＴＥメッセージを受信すると、メディアゲートウエイ制御装置１３０は、開始通信装置すなわち通信装置１１１が複数参加者通信セッションのセットアップを要求していることを確認する。メディアゲートウエイ制御装置１３０は、通信装置すなわち通信装置１１２−１１４がセッションへの参加を招待されていることを確認する。次に、メディアゲートウエイ制御装置１３０は、メディアゲートウエイすなわちメディアゲートウエイ１２０を通信セッションに割り当て、メディアゲートウエイ１２０に、メディアゲートウエイに関連したルーティングアドレス、好ましくはＩＰアドレスおよびポート番号を通信セッションの参加者すなわちノード１０１−１０４の各々に対応する各ノードに割り当てるように指示する。その指示の受理に応答して、メディアゲートウエイ１２０は、複数のメディアゲートウエイＩＰアドレスおよび複数のメディアゲートウエイポートをセッションに割り当て、割り当てたＩＰアドレスおよびポートをメディアゲートウエイ制御装置１３０に報告する。次に、メディアゲートウエイ制御装置１３０は、複数のメディアゲートウエイＩＰアドレス／ポートの組み合わせ１２０ａ−１２０ｄ（４つを示す）の１つを、セッションに参加している各ノード１０１−１０４に割り当て、割り当てたアドレス／ポートの組み合わせをメディアゲートウエイ１２０に通知する。メディアゲートウエイ制御装置１３０は、対応するノード１０１−１０４のＩＰアドレスおよびポートと、各割り当てられたメディアゲートウエイアドレス／ポートとの組み合わせ１２０ａ−１２０ｄの結合についてもメディアゲートウエイ１２０に通知し、それによって、次に受信されるＳＩＰおよびＲＴＰデータパケットをどこに送るべきかをメディアゲートウエイ１２０に通知する。

本発明の他の実施形態において、メディアゲートウエイ制御装置１３０は、メディアゲートウエイ１２０に、１つのＩＰアドレスおよびポートを通信セッションに割り当てるよう指示することができる。その指示の受理に応答して、メディアゲートウエイ１２０は、メディアゲートウエイＩＰアドレスおよびメディアゲートウエイポートをセッションに割り当て、割り当てたＩＰアドレスおよびポートをメディアゲートウエイ制御装置１３０に報告する。次に、メディアゲートウエイ制御装置１３０は、メディアゲートウエイＩＰアドレス／ポートの組み合わせをセッションに参加しているノード１０１−１０４の各々に割り当て、割り当てたアドレス／ポートの組み合わせ、およびノード１０１−１０４に対応するＩＰアドレスおよびポートと割り当てたメディアゲートウエイアドレス／ポートの組み合わせの結合について、メディアゲートウエイ１２０に通知し、それによって、次に受信されるＳＩＰおよびＲＴＰデータパケットをどこに送るべきかをメディアゲートウエイ１２０に通知する。次に、メディアゲートウエイ１２０は割り当てたポートをモニタし、下に説明するトーカアービトレーションメカニズムに従ってポートに到達する音声パケットをすべて複製する。メディアゲートウエイ１２０に到達する各音声パケットは、ソースＩＰアドレス、およびパケットに含まれるＳＳＲＣ／ＣＳＲＣパラメータ（このパラメータについては以下に説明する）によって完全に識別される。

次に、メディアゲートウエイ制御装置１３０は、ＳＩＰ＿ＩＮＶＩＴＥメッセージをセッションへ招待された１人または２人以上の各々にすなわち通信装置１１２−１１４に、メディアゲートウエイ１２０および通信装置１１２−１１にそれぞれ関連するノード１０２−１０４を介して送信する。各ＳＩＰ＿ＩＮＶＩＴＥメッセージのＳＤＰは、メディアゲートウエイ制御装置１３０によって受信ノードに割り当てられたメディアゲートウエイ１２０のアドレス／ポートの組み合わせを受信ノードおよび／または通信装置に通知する
情報を含み、それによって、次のＳＩＰおよびＲＴＰデータパケットをどこに送るべきかを通信装置および／またはノードに通知する。

ＳＩＰ＿ＩＮＶＩＴＥメッセージの受信に応答して、各招待された人すなわち通信装置１１２−１１４の各々は、ＳＩＰ＿ＯＫメッセージを開始通信装置すなわち通信装置１１１にＩＰネットワーク１０６を介して送る。次に、開始通信装置１１１は、応答通信装置にＳＩＰ＿ＡＣＫＮＯＷＬＥＤＧＭＥＮＴメッセージを送信することにより、各ＳＩＰ＿ＯＫメッセージを肯定し、通信システム１００は、複数の参加者間で音声およびデータパケットを交換する周知の方法に従ってＲＴＰメディアセッションをセットアップする。上記のごとく、セッションのセットアップ時に参加者によって交換されるＳＩＰメッセージは、参加者に提供されるサービスおよび機能を含んだ、参加者が自発的に確立したいＲＴＰメディアセッションの形態に関するネゴシエーション（ｎｅｇｏｔｉａｔｉｏｎ）を提供する。

ＩＰネットワーク１０６、好ましくはメディアゲートウエイ制御装置１３０、または代わりにメディアゲートウエイ１２０は、通信セッションのセットアップおよびネゴシエーション中に交換された各ＳＩＰメッセージのＳＤＰ部を調べる。セッションネゴシエーションが、例えば、参加ノード１０１−１０４の第１のノードが参加ノード１０１−１０４の第２のノードによって利用される第２のボコーダとは異なる第１のボコーダを有する、または、参加ノード１０１−１０４の第１のノードが、参加ノード１０１−１０４の第２のノードによって利用される汎用移動体通信システム（ＵＭＴＳ）のような第２の規格またはメッセージ形式とは異なるパルス符号変調（ＰＣＭ）のような第１の規格またはメッセージ形式に準じて動作する、といったような、ノード間のメッセージ形式が非互換性であることを示す場合、メディアゲートウエイ制御装置１３０は、セッションに参加する他のノードによって使用されるボコーダとは異なるボコーダを使用するノードのような、非互換性のノードを切り捨てることができる。

本発明の他の実施形態において、ＩＰネットワーク１０６は、あるプロトコルまたは規格から他のプロトコルまたは規格のように、メッセージをあるフォーマットから他のフォーマットに変換可能な１つまたは２つ以上のトランスレータ１２２（１つを図に示す）を含むことができる。１つまたは２つ以上のトランスレータ１２２の各々は、メディアゲートウエイ１２０に含まれていてもよく、またメディアゲートウエイ１２０に接続されて動作するアプリケーションプラットホームに含まれていてもよい。メディアゲートウエイ制御装置１３０が、セッションへの参加を招待されたノード間の、ボコーダまたは規格の非互換性のようなフォーマットの非互換性を確認すると、メディアゲートウエイ制御装置１３０は、非互換性のノードとの通信を変換するために適切なトランスレータ１２２を割り当てる。次に、割り当てられたトランスレータ１２２は、通信セッション中にメディアゲートウエイ１２０と非互換性ノードとの間で交換されたＲＴＰデータパケットを変換する。

ＲＴＰメディアセッションが確立されると、音声データは、ＲＴＰに準じてフォーマットされると共に通信装置１１１−１１４のそれぞれの信号処理装置１１６によって組み立てられたデータパケットを使用して、通信セッションに含まれる複数の通信装置すなわち通信装置１１１−１１４間で交換される。図２は、先行技術の典型的なＲＴＰデータパケットのビットマップである。ＲＴＰデータパケット２００は、複数のデータフィールド２０１−２１０を含んだＲＴＰ固定ヘッダと、ペイロードデータフィールド２１２とを含む。ＲＴＰデータパケット２００は、さらに未定義のＲＴＰヘッダ拡張子データフィールド２１１を任意選択で含んでいてもよい。固定ヘッダは、使用されるＲＴＰバージョンを識別する「バージョン」データフィールド２０１と、値「１」にセットされた時、データパケット２００がパケットの終わりに１つまたは２つ以上の追加のパディングオクテット（
ｐａｄｄｉｎｇ ｏｃｔｅｔ）（そのオクテットはペイロードの一部ではない）を含むことを示す「パディング」データフィールド２０２とを含む。固定ヘッダは、値「１」にセットされた時、固定ヘッダの後にヘッダ拡張子が続くことを示す「拡張子」データフィールド２０３と、固定ヘッダに続くＣＳＲＣ識別子の数を含む「寄与ソースカウント（Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅ Ｃｏｕｎｔ）」（ＣＳＲＣ）データフィールド２０４とをさらに含む。

固定ヘッダの「マーカ（ｍａｒｋｅｒ）」データフィールド２０５は、データフレームの境界のようなデータパケットストリームの重要なイベントのマーキングを与え、プロファイルによって識別される。固定ヘッダの「ペイロードタイプ（ｐａｙｌｏａｄ ｔｙｐｅ）」データフィールド２０６は、ＲＴＰペイロードのフォーマットを識別するコードを含む。プロファイルがペイロードタイプコードのデフォルトの静的なマッピングをペイロードフォーマットに指定するので、ペイロードタイプコードは、受信通信装置のアプリケーションによってペイロードの解釈を決定する。固定ヘッダの「シーケンス（ｓｅｑｕｅｎｃｅ）」データフィールド２０７は、関連したデータパケット群の各データパケットに連続した番号付けを行う。受信通信装置は、データパケット損失を検知し、パケットがシーケンスから外れて受信された場合にデータパケットシーケンスを回復するために、その連続番号を使用できる。固定ヘッダの「タイムスタンプ」データフィールド２０８は、ＲＴＰデータパケットの第１のオクテットのサンプリング時点を識別する。受信通信装置は、タイムスタンプを同期のため、およびデータパケット到達の微小変動（ｊｉｔｔｅｒ）を測定するために使用できる。固定ヘッダの「同期ソースカウント（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅ Ｃｏｕｎｔ）」（ＳＳＲＣ）データフィールド２０９は、ＲＴＰパケットの発信者を一意的に識別する。固定ヘッダの「ＣＳＲＣ」データフィールド２１０は、データパケットに含まれているペイロードの寄与ソースに関連した識別子のリストを含む。

高速でかつＲＴＰセッションのフレームワーク内で行うことができる、複数参加者通信セッションにおける話者アービトレーションまたは「フロア管理」を提供するために、通信システム１００は、ＲＴＰフロア管理メッセージを使用した「インバンド」フロア管理を提供している。各ＲＴＰフロア管理メッセージは、ＲＴＰフロア管理ヘッダ拡張子を含むＲＴＰデータパケットを有している。図３は、本発明の実施形態によるＲＴＰフロア管理メッセージ３００のビットマップである。各ＲＴＰフロア管理メッセージ３００は、通信装置１１１−１１４のそれぞれの信号処理装置１１６またはメディアゲートウエイ１２０の信号処理装置１２４のような、メッセージを送信するシステム１００の構成要素の信号処理装置によって組み立てられるのが好ましい。ＲＴＰデータパケット２００同様、ＲＴＰフロア管理メッセージ３００は、ペイロードデータフィールド３１２と、バージョンデータフィールド３０１、パディングデータフィールド３０２、拡張子データフィールド３０３、ＣＳＲＣカウントデータフィールド３０４、マーカデータフィールド３０５、ペイロードタイプデータフィールド３０６、シーケンスデータフィールド３０７、タイムスタンプデータフィールド３０８、ＳＳＲＣデータフィールド３０９、およびＣＳＲＣデータフィールド３１０を含む固定ヘッダ３０１−３１０と、を有する。

ＲＴＰデータパケット２００と異なり、ＲＴＰフロア管理メッセージ３００は、複数のフロア管理サブフィールド３２１−３２３を含むＲＴＰフロア管理ヘッダ拡張子データフィールド３１１をさらに含む。ＲＴＰフロア管理ヘッダ拡張子３１１の第１のサブフィールド３２１は、ＲＴＰデータパケットをＲＴＰフロア管理メッセージであると確認し、ＲＴＰフロア管理メッセージの種類をさらに識別する、フロア管理メッセージタイプデータフィールドを有する。ＲＴＰフロア管理ヘッダ拡張子３１１の第２のサブフィールド３２２は、ＲＴＰフロア管理ヘッダ拡張子の長さを識別する。ＲＴＰフロア管理ヘッダ拡張子３１１の第３のサブフィールド３２３は、サブフィールド３２１によって識別されたＲＴ
Ｐフロア管理メッセージに対応するフロア管理データで、好ましくは話者アービトレーションコマンドで埋められている。ＲＴＰフロア管理ヘッダ拡張子３１１の存在に対する警告を受信通信装置に行うために、ＲＴＰフロア管理メッセージ３００の拡張子データフィールド３０３は、値「１」で埋められている。

通信システム１００は、インバンドフロア管理プロトコルを通信装置間で実行することにより、内在するネットワークおよび装置に対してトランスペアレント（透明）なフロア管理プロトコルを提供する。複数パーティの通信セッション用のフロア管理プロトコルの実用的な配置という点においては、通常、インフラストラクチュアと遠方の構成要素内の、およびそれらの間の様々な位置に配置されるファイアウォールを介在させることが必要であろう。ＳＩＰおよびＲＴＰがファイアウォールに侵入するために、ファイアウォールによる会議のＳＤＰセッティングのモニタを可能にし、ファイアウォール管理者によってセットアップされた規則に基づいてパケットがファイアウォールを通り抜けできるまたは通り抜けできないようにする方法が当業界では知られている。「帯域外」フロア管理プロトコルは、管理プロトコルが透明に通過できるようにするために追加のファイアウォールサービスが必要であるという問題がある。ＲＴＰデータパケットのベアラペイロード構成内にフロア管理プロトコルを埋め込むことによって、管理情報のタイムリーな配信、および任意の介在セキュリティ対策による自由なアクセスが確保される。

話者アービトレーション用の処理を提供するために、通信システム１００によって行われる複数のＲＴＰフロア管理メッセージは、次の６つのフロア管理メッセージを含むのが好ましい。複数のＲＴＰフロア管理メッセージの第１のメッセージは、フロアの確保を要求するすなわち複数参加者通信セッションの話者のようなユーザ情報送信装置であることを要求する送信要求メッセージである。送信要求メッセージを含むＲＴＰパケットは、音声サンプルをさらに含んでいてもよい。１人の参加者だけが任意の特定の時間にフロアを確保できるので、音声パケットの発信元が所定の時間に話すことが許可されていない場合、音声パケットに含まれる音声は無視される。複数のＲＴＰフロア管理メッセージの第２のメッセージは、送信要求メッセージに応答して要求側にフロアを許可する送信許可メッセージである。複数のＲＴＰフロア管理メッセージの第３のメッセージは、フロアが許可された後、被許可者からのデータ送信の開始を特定する送信開始メッセージである。複数のＲＴＰフロア管理メッセージの第４のメッセージは、被許可者によるフロアの管理が放棄され、フロアが通信セッションの他の参加者による予約に対して解放されていることを示す送信終了メッセージである。複数のＲＴＰフロア管理メッセージの第５のメッセージは、他の応答がない場合、送信要求メッセージに対する一般的な応答として使用され得る肯定メッセージである。複数のＲＴＰフロア管理メッセージの第６のメッセージは、要求側のフロアの確保要求を否定する要求否定メッセージである。

参加者間で交換可能なＲＴＰフロア管理メッセージの提供および複数参加者ＩＰ通信セッションに含まれるＩＰネットワークの介在によって、通信システム１００は、高速で、かつ現在の既存のＩＰネットワークに対する最小限の変更で作動する、インバンド話者アービトレーションを提供する。送信許可メッセージ、肯定メッセージ、および要求否定メッセージの各々は、要求側を一意的に識別する情報を含み、送信開始メッセージは、被許可者を一意的に識別する情報を含むのが好ましい。

ここで図４を参照して、本発明の実施形態による複数参加者通信セッションの通信システム１００の話者アービトレーションプロセスを図示するメッセージフローチャート４００を示す。ユーザ情報を送信する、すなわちユーザデータについて話しまたは送信するためにフロアを確保することを要望している通信装置１１２のユーザのような、複数参加者通信セッションの参加者が、その参加者の通信装置すなわち通信装置１１２にフロア確保要求を入力する（４０２）と、メッセージフローチャート４００が開始される。例えば、
参加者は、フロアを確保するユーザの要望を示す無線電話キーパッドの「押して話す」（Ｐｕｓｈ−Ｔｏ−Ｔａｌｋ：ＰＴＴ）キーのような、キーパッドのキーを押し下げてもよい。その要求の受信に応答して、通信装置１１２はＲＴＰフロア管理送信要求メッセージを組み立て（４０４）、そのメッセージを対応ノード１０２を介してＩＰネットワーク１０６、特にメディアゲートウエイ１２０に送信する。

送信要求メッセージの受信に応答して、ＩＰネットワーク１０６、特にメディアゲートウエイ１２０は、フロアが利用可能かどうかを判断する（４０６）。本発明の他の実施形態において、メッセージフローチャート４００に関してメディアゲートウエイ１２０によって行なわれる１つまたは２つ以上の機能は、システム１００の設計者によってメディアゲートウエイ１２０で行われる知能程度に応じ、メディアゲートウエイ制御装置１３０によって行なわれてもよい。メディアゲートウエイ１２０が、フロアが利用可能でなく、例えばフロアが通信装置１１１のような通信セッションに参加している他の通信装置によって確保されていると判断した場合、メディアゲートウエイ１２０は、フロア確保の要求が許可されないというＲＴＰフロア管理メッセージを要求側すなわち通信装置１１２に送信する。本発明の一実施形態において、フロア確保の要求が許可されないというメッセージは、送信否定メッセージであってもよい（４０８）。例えば、通信装置１１１は、データをメディアゲートウエイ１２０に活発に送信し、通信セッションの他の参加者に配信できる。他の例として、通信装置１１１は、送信終了メッセージをメディアゲートウエイ１２０に送信することによってフロアの解放を試みたが、メディアゲートウエイは、通信装置１１１による確保からまだフロアを解放していない。送信否定メッセージが要求側を識別する情報を含む場合、メディアゲートウエイ１２０は、ＩＰマルチキャストを使用して１つまたは２つ以上の送信否定メッセージを送信してもよい。メッセージは、要求側すなわち通信装置１１２と、１人または２人以上の他の参加者すなわち１つまたは２つ以上の通信装置１１１、１１３、および１１４の両方に複製される。次に、他の参加者は、要求側を識別する情報を使用してメッセージが自分たちに向けられたものでないことを判断し、メッセージを無視することを選択できる。

本発明の他の実施形態では、フロア確保の要求が許可されなかった要求側にメディアゲートウエイ１２０によって送信されるメッセージは、ＲＴＰフロア管理肯定メッセージであってもよい（４１０）。下に説明するように、複数の参加者がフロアを要求し、メディアゲートウエイ１２０が異なる参加者にフロアの使用許可を与えるといった本発明のさらに他の実施形態では、フロア確保の要求が許可されなかった要求側にメディアゲートウエイによって送信されるメッセージは、他の人にフロアを許可するＲＴＰフロア管理送信許可メッセージであってもよい（４１６）。ＲＴＰフロア管理送信要求メッセージの送信に応答して、要求側にフロアを許可するＲＴＰフロア管理送信許可メッセージ以外のメッセージが、要求側によってすなわち要求側の通信装置によって受信されることで、要求側の通信装置は、要求側のフロアを確保する要求が否定されたことを通知される。

メディアゲートウエイ１２０が、フロアが解放されているすなわち確保が可能であると判断した場合、メディアゲートウエイは、ＲＴＰフロア管理送信許可メッセージを要求側すなわち通信装置１１２と、要求側の通信装置に関連したノードすなわちノード１０２に送信する（４１４）。フロアは、もはや確保されていないので解放されてもよいか、あるいは、メディアゲートウエイ１２０が１つの通信装置によって確保されていたフロアを他の通信装置による確保のために解放することを決定したので解放されてもよい。例えば、話者が連続的な所定の時間の間フロアを確保してしまった後、通信システム１００は、話者が優先買取の資格がある、すなわち話者のフロア確保を喪失させる権利を行使できる話者優先のプロセスを行うことができる。他の実施例として、第２の通信装置が緊急通信を送信するためにフロアを要求した場合、通信システム１００は、第１の通信装置が第２の通信装置のためにフロアの確保を喪失し得る緊急オーバーライドプロセスを行うことがで
きる。

送信許可メッセージは、要求側がフロアの確保を許可されており、ユーザデータについて発話または送信の開始が可能なこと要求側に通知する。本発明の他の実施形態では、被許可者への送信許可メッセージの送信に加えて、メディアゲートウエイ１２０は、被許可者すなわち通信装置１１２、および／または被許可者に関連したノードすなわちノード１０２を識別するＲＴＰフロア管理送信許可メッセージを、通信セッションの１人または２人以上の他の参加者にすなわち１つまたは２つ以上の通信装置１１１、１１３、および１１４に、参加者に関連したノードを介して付加的に送信できる（４１６）。送信許可メッセージは被許可者を識別する情報を含むので、メディアゲートウエイ１２０は、単一の送信許可メッセージを被許可者すなわち通信装置１１２と、１人または２人以上の他の参加者すなわち１つまたは２つ以上の通信装置１１１、１１３、および１１４との両方に、ＩＰマルチキャストを使用して複製できる。

本発明のさらに他の実施形態では、メディアゲートウエイ１２０は、送信要求メッセージを通信装置１１２、１１３、および１１４のような複数の参加者の通信装置の各々から受信できる。複数の送信要求メッセージは、メディアゲートウエイ１２０によって同時に受信されてもよく、または互いに事前またはダイナミックに決定された時間内で受信されてもよく、それによって、地理的に遠方の通信装置は、より近い通信装置と同じ基準でフロアを得る競争することができるようにしている。メディアゲートウエイ１２０が、フロアが利用可能でないと判断した場合、メディアゲートウエイは、各要求側にすなわち通信装置１１２、１１３、および１１４の各々にＲＴＰフロア管理送信否定メッセージ（４０８）を送信する。メディアゲートウエイ１２０が、フロアが利用可能であると判断した場合には、メディアゲートウエイ、特にメディアゲートウエイのアービトレーション論理演算装置１２８は、メディアゲートウエイの１つまたは２つ以上の記憶装置に格納されたアービトレーションアルゴリズムを実行し（４１２）、複数の確保要求の中から許可する確保要求を選択する。本発明の他の実施形態では、アービトレーション論理演算装置１２８は、メディアゲートウエイの代わりにメディアゲートウエイ制御装置１３０に常駐し、メディアゲートウエイ制御装置１３０の記憶装置に格納されたアービトレーションアルゴリズムを実行できる。

当業者は、多くの周知のアービトレーションアルゴリズムの中の任意の１つが、本発明の精神と範囲から外れることなくここで使用できることを理解するであろう。例えば、通信システム１００は、各通信装置１１１−１１４に階層的ランキングのような優先順位を割り当てることができる。複数の通信装置１１２−１１４の各々から送信要求メッセージを受信すると、メディアゲートウエイ１２０は、装置によって送信されたＲＴＰフロア管理送信要求メッセージのＳＳＲＣデータフィールド２０９に含まれる識別子に基づいて、複数の通信装置の各々の優先順位を決定する。その決定された優先順位に基づいて、アービトレーション論理演算装置１２８は、アービトレーションアルゴリズムを実行して最優先順位を有する通信装置を確定し、その通信装置にフロアを許可するのが好ましい。

他の実施例として、許可すべき確保要求に関する判断は、メディアゲートウエイ１２０またはメディアゲートウエイ制御装置１３０が、通信セッションの各参加者がフロアを許可された回数の記録を保持するラウンドロビンアルゴリズム（ｒｏｕｎｄ ｒｏｂｉｎ ａｌｇｏｒｉｔｈｍ）に基づいていてもよい。アービトレーション論理演算装置１２８は、各参加者がフロアを許可された回数に基づいて、メディアゲートウエイ１２０の記憶装置に格納されたアービトレーションアルゴリズムを実行し、最も少ない許可回数を有する参加者を算出し、その参加者にフロアを許可することが好ましい。アービトレーションアルゴリズムの他の実施例として、複数の要求の中の各要求の到着時間に基づく優先順位、および複数の参加者の中の各参加者の位置に基づく優先順位が挙げられる。

フロアが利用可能なことを算出し、複数の送信要求メッセージが受信されたときにフロアの確保を許可する要求側をさらに特定すると、メディアゲートウエイ１２０は、ＲＴＰフロア管理送信許可メッセージを被許可者に送信する（４１４）。本発明の一実施形態において、複数の送信要求メッセージが受信された場合、メディアゲートウエイ制御装置１３０は、フロアを許可された被許可者を特定したＲＴＰフロア管理送信許可メッセージを、フロアの確保を要求した他の参加者の各々にさらに送信する（４１６）。本発明の他の実施形態では、フロアが利用可能なことを算出し、複数の送信要求メッセージが受信されたときにフロアの確保を許可する要求側をさらに特定すると、メディアゲートウエイ制御装置１３０およびメディアゲートウエイ１２０は、ＩＰマルチキャストを使用して、フロア確保の要求を許可するＲＴＰフロア管理メッセージを通信セッションの複数の参加者の各々に複製して送信してもよい。次に、フロアの確保を要求した複数の参加者の各々は、メッセージによって識別された被許可者に基づいて、自身がフロアを許可または拒絶されたかを判断できる。本発明のさらに他の実施形態では、複数の送信要求メッセージが受信された場合、メディアゲートウエイ制御装置１３０は、フロアの確保を要求したがフロアを否定されている他の参加者の各々に、ＲＴＰフロア管理送信否定メッセージを送信できる（４１８）。本発明のさらに他の実施形態では、メディアゲートウエイ制御装置１３０は、フロアの確保を要求したがフロアを否定されている他の参加者の各々に、ＲＴＰフロア管理肯定メッセージを送信できる（４２０）。次に、フロアの確保を要求した複数の参加者の各々は、被許可者として参加者をリストに列挙しているＲＴＰフロア管理送信許可メッセージ以外のメッセージを参加者が受信することによって、自身がフロアを拒否されたことを判断できる。

被許可者の通信装置１１２は、送信許可メッセージの受信に応答して、ユーザがフロアを許可されたという指示を被許可者通信装置のユーザに与える（４２２）。例えば、被許可者通信装置は、発信音を初めとする、音による指示をユーザに与えてもよく、または通信装置は、不活性な発光ダイオード（ＬＥＤ）を活性化する、あるいは活性なＬＥＤを不活性化するといったような、目に見える指示をユーザに与えてもよい。ユーザは、フロアの確保を許可されたということが通知されると、次に、音声データまたは他のユーザ情報を通信セッションの他の参加者に送信できる。ユーザは、音声または他のユーザデータを有するユーザ情報をユーザの通信装置すなわち通信装置１１２に入力する（４２４）。そのユーザ情報の受信に応答して、通信装置１１２は、ユーザ情報を含む１つまたは２つ以上のＲＴＰデータパケット２００を組み立て、要求側のノード１０２および要求側のノードに関連したメディアゲートウエイアドレス／ポートの組み合わせ１２０ｂを介して、１つまたは２つ以上のＲＴＰデータパケットをメディアゲートウエイ１２０に送信する（４２６）。１つまたは２つ以上のユーザデータＲＴＰデータパケットの各々は、ペイロードデータフィールド２１２に埋め込まれたユーザ情報と、拡張子データフィールド２０３に埋め込まれた値「０」とを含む。

メディアゲートウエイ１２０が、ユーザ情報を含む各ＲＴＰデータパケットを被許可者通信装置１１２から受信すると、メディアゲートウエイ１２０は、受信したデータパケットに含まれるユーザ情報のコピーを生成する。次に、メディアゲートウエイ１２０は、通信セッションに割り当てられたメディアゲートウエイアドレス／ポートの組み合わせ１２０ａ、１２０ｃ、１２０ｄ行きの、各ノード１０１、１０３、１０４のユーザ情報を含むＲＴＰパケットを組み立て、ユーザ情報のコピーを有する組み立てられたＲＴＰデータパケットを、通信セッションの他の参加者の各々にそれらの対応するノードを介して送信する（４２８）。例えば、メディアゲートウエイ１２０が、ユーザ情報を有するＲＴＰデータパケットを通信装置１１２から受信すると、セッションに参加している他の通信装置すなわち通信装置１１１、１１３、および１１４の少なくとも１つに関連づけられ、セッションに割り当てられたメディアゲートウエイアドレス／ポートの組み合わせ１２０ａ、１
２０ｃ、１２０ｄに結合された各ノード１０１、１０３、１０４のために、メディアゲートウエイは、受信したＲＴＰパケットに含まれるユーザ情報のコピーを作成する。メディアゲートウエイ１２０は、ユーザ情報のコピーを含むそのようなノードの各々のためにＲＴＰデータパケットを組み立てる。次に、メディアゲートウエイ１２０は、組み立てたＲＴＰデータパケットを、それぞれのノード１０１、１０３、１０４、およびノードに関連したそれぞれのメディアゲートウエイアドレス／ポートの組み合わせ１２０ａ、１２０ｃ、および１２０ｄを介して、各通信装置１１１、１１３、１１４に送る。

被許可者通信装置のユーザがユーザ情報を送信し終えると、被許可者は、フロアを解放したいという自身の要望を被許可者通信装置すなわち通信装置１１２に示す（４３０）ことによってフロアの解放を開始する。例えば、ユーザは単に装置に向かって話すのを止めてもよいし、またはユーザは、ユーザがフロアを確保してユーザ情報を送信したいと望んでいる間中ユーザが押し下げ続けていたＰＴＴキーを解放してもよい。フロアを解放したいという被許可者の要望に関するユーザ指示の受理に応答して、被許可者通信装置は、フロアの解放を決定し、ＲＴＰフロア管理送信終了メッセージを組み立てる。ＲＴＰフロア管理送信終了メッセージは、フロアの確保を解除したい送信者の意図を、メッセージの受信者に通知する。次に、被許可者通信装置は、ＩＰネットワーク１０６、特にメディアゲートウエイ１２０に、ＲＴＰフロア管理送信終了メッセージを送信する（４３２）。

メディアゲートウエイ１２０はＲＴＰフロア管理送信終了メッセージを受信し、そのメッセージの受信に応答して、通信セッションの他の参加者の各々に対する、ＲＴＰフロア管理送信終了メッセージを生成する。別の選択肢として、メディアゲートウエイ１２０は、他の参加者の各々への送信のために、受信した送信終了メッセージの複写を作成してもよい。次に、メディアゲートウエイ制御装置１３０は、ＲＴＰフロア管理送信終了メッセージを、通信セッションの他の参加者の各々に送信する（４３４）。本発明の他の実施形態では、送信終了メッセージの受信に応答して、メディアゲートウエイ１２０は、送信終了メッセージの受理を肯定するＲＴＰフロア管理肯定メッセージも生成し、ＲＴＰフロア管理肯定メッセージを被許可者通信装置すなわち通信装置１１２に送信する（４３６）。ＲＴＰフロア管理送信終了メッセージの受信に応答して、各参加者の通信装置すなわち通信装置１１１、１１３、および１１４は、チャネルが確保可能であることを装置のユーザに示す（４３８）。当業者は、本発明の精神と範囲から逸脱することなくここで使用できる、発信音を初めとする、音による指示のような、あるいは、送信終了メッセージの受信と同時に活性化または不活性化されるＬＥＤを初めとする、目に見える指示のような、フロアの利用可能性を表示する多くの方法があることを理解するであろう。

本発明の他の実施形態では、１つまたは２つ以上のノード１０１−１０４は、図１−図４に関して上に説明したＲＴＰフロア管理メッセージの交換をサポートできない。そのような実施形態では、メディアゲートウエイ１２０は、ＲＴＰの異なるバージョンをサポートするノードを相互接続するのに利用可能な、少なくとも１つのインタワーキング機能ユニット（ＩＷＦ）１２６（１つを示す）をさらに含んでいてもよい。この実施形態では、通信セッションをセットアップする際に参加者によって交換されるＳＩＰメッセージのＳＤＰ部が、ノード１０１−１０４の各々によってサポートされるＲＴＰのバージョンを通知する。１つまたは２つ以上のノード１０１−１０４が、ノード１０１−１０４の１つまたは２つ以上の他のノードにサポートされているバージョンとは異なるＲＴＰのバージョンをサポートしているとメディア制御装置１３０が判断した場合、メディア制御装置１３０は、ＩＷＦ１２６を割り当てるようメディアゲートウエイ１２０に指示し、２つのノード間の通信を再フォーマットするか、またはＲＴＰの１つのバージョンによってサポートされているがＲＴＰの別のバージョンによってはサポートされていないメッセージを生成し、それによって、ＲＴＰの様々なバージョンをサポートするノードが互いに通信セッションに携わることを可能にする。

例えば、上記のごとく、ノード１０１−１０３の各々は、ＲＴＰヘッダ拡張子を使用した話者アービトレーションを含むＲＴＰのバージョンをサポートできるが、ノード１０４は、ヘッダ拡張子を含まないＲＴＰのバージョンをサポートするレガシーノード（ｌｅｇａｃｙ ｎｏｄｅ）であってもよい。次に、メディアゲートウエイ制御装置１３０は、パケットがノード１０４によってサポートされたフォーマットになるように、ＩＷＦ１２６を割り当て、ノード１０１−１０３から受信してノード１０４に向けられるパケットを処理してもよい。ＩＷＦ１２６が、ノード１０１−１０３の中の１つからノード１０４に向けられた、ヘッダ拡張子を含むＲＴＰデータパケットを受信すると、ＩＷＦ１２６はヘッダ拡張子を無視し、ノード１０４用にＲＴＰデータパケットの残りの部分を処理する。

ＩＷＦ１２６は、ノード１０４がノード１０１−１０３との話者アービトレーションに携われるように、レガシーノード１０４のためにＲＴＰフロア管理メッセージを生成することもできる。例えば、ＩＷＦ１２６は音声と沈黙を識別できるのが好ましい。フロアが利用可能になり、ＩＷＦ１２６がノード１０４から非沈黙ＲＴＰデータパケットを受信すると、ＩＷＦは、ノード１０４のためにＲＴＰフロア管理送信要求メッセージを生成してもよい。送信要求メッセージの送信に応答して、ノード１０４がフロアを否定されると、ＩＷＦ１２６は、次にノード１０４から受信したＲＴＰメッセージを阻止する。送信要求メッセージの送信に応答して、ノード１０４がフロアを与えられると、ＩＷＦ１２６は、次にノード１０４から受信したＲＴＰメッセージを送信する。そして、ノード１０４がフロアを許可されたが、その後所望の期間中沈黙を続けている場合には、ＩＷＦ１２６は、ノード１０４のためのフロアの管理を放棄するＲＴＰフロア管理送信終了メッセージを生成できる。

本発明のさらに他の実施形態では、ＩＷＦ１２６は、ＩＤＥＮ（統合ディジタルエンハンストネットワーク）やＲＴＰヘッダ拡張子を使用した話者アービトレーションを含むＲＴＰバージョンのような複数のパケットデータプロトコルをサポートし、あるプロトコルをサポートするノードとその他のプロトコルをサポートするノード間のデータパケットを変換できる。

一般に、通信システム１００は、ＲＴＰデータパケットヘッダ拡張子に埋め込まれた話者アービトレーションコマンドを含む複数のＲＴＰフロア管理メッセージ３００を使用して、複数参加者通信セッションにおけるインバンド話者アービトレーションを提供する。ＲＴＰフロア管理メッセージ３００は、フロアの確保を要求する送信要求メッセージと、要求側にフロアを許可する送信許可メッセージと、送信要求メッセージに応答して、フロアが許可された後の被許可者によるデータ送信の開始を特定する送信開始メッセージと、被許可者によるフロアの管理が放棄され、フロアが通信セッションの他の参加者による予約に対して解放されていることを示す送信終了メッセージと、他の応答がない場合に送信要求メッセージへの一般的な応答として使用できる肯定メッセージと、要求側のフロアを確保する要求を否定する要求否定メッセージとを含む。ＲＴＰフロア管理メッセージがメディアゲートウエイ１２０によって受信された場合、ゲートウェイは、そのメッセージに応答するＲＴＰフロア管理メッセージをメッセージの搬送者および／または通信セッションの他の参加者に送信してもよいし、または他の参加者に送信するメッセージを複製してもよい。通信システム１００は、受信したフロア管理メッセージまたはそのメッセージに応答するフロア管理メッセージの複製および送信のために、ＩＰマルチキャストを利用することもできる。通信装置間のインバンドフロア管理プロトコルを行うことによって、通信システム１００は、内在するネットワークおよび装置に対してトランスペアレントなフロア管理プロトコルを提供し、それによって、制御情報のタイムリーな配信、および任意の介在するセキュリティ対策によるフリーアクセスの確保を可能にしている。

図５は、本発明のさらに別の実施形態による通信システム５００のブロック図である。通信システム１００同様、通信システム５００において、通信装置１１１および１１２の各々は、ＩＰネットワーク１０６の第１のメディアゲートウエイ１２０および第１のメディアゲートウエイ制御装置１３０と、ノード１０１および１０２を介してそれぞれ通信する。しかし、通信システム１００と異なり、通信システム５００では、通信セッションに含まれる通信装置１１３および１１４の各々は、それぞれのノード１０３および１０４を介して、第１のメディアゲートウエイ１２０およびメディアゲートウエイ制御装置１３０、およびＩＰネットワーク１０６に含まれる第２のメディアゲートウエイ５２０と通信する。通信システム５００の一実施形態において、第１のメディアゲートウエイ１２０および第２のメディアゲートウエイ５２０は各々、同じメディアゲートウエイ制御装置１３０によって制御される。本発明の他の実施形態では、第１のメディアゲートウエイ１２０は第１のメディアゲートウエイ制御装置１３０によって制御され、第２のメディアゲートウエイ５２０は第２のメディアゲートウエイ制御装置５３０によって制御される。

通信システム５００の一実施形態において、ノード１０３および１０４の各々は、システム５００の機構の一部として第２のメディアゲートウエイ５２０に接続されて動作する。通信システム５００の他の実施形態において、メディアゲートウエイ制御装置１３０は、通信装置１１１−１１４を含む通信セッションのセットアップ中、第２のメディアゲートウエイ５２０をダイナミックに割り当て、ノード１０３および１０４にサービスを提供する。通信システム５００のさらに別の実施形態において、通信装置１１１−１１４が関わる通信セッションのセットアップ中、メディアゲートウエイ制御装置１３０は、他のメディア制御装置５３０がノード１０３および１０４にサービスを提供すべきことを決定できる。次に、メディアゲートウエイ制御装置１３０は、セッション中、ノードにサービスを提供するように第２のメディアゲートウエイ制御装置５３０に指示し、そのノードに第２のメディアゲートウエイ５３０を割り当てる。複数のゲートウェイ１２０、５２０が通信セッションで利用される場合、複数のゲートウェイの中の１つのゲートウェイ（例えばメディアゲートウエイ１２０）は、マスターに指定され、複数のゲートウェイの中の１つまたは２つ以上の他のゲートウェイ（例えばメディアゲートウエイ５２０）は各々、スレーブに指定されるのが好ましい。次に、フロア管理決定およびアービトレーションアルゴリズムは、マスターゲートウェイ（つまりゲートウェイ１２０）および関連するゲートウェイ制御装置（つまりゲートウェイ制御装置１３０）によって行なわれる。

例えば、メディアゲートウエイ制御装置１３０は、通信セッションをセットアップするのに使用されるＳＩＰメッセージの交換中、通信セッションへの参加を招待された複数のノードすなわちノード１０３、１０４が、例えば、同じ非互換性のメッセージ形式を使用する、または同じ非互換性のボコーダを持っているといった同じ非互換性に煩わされることを確認するかもしれない。次に、メディアゲートウエイ制御装置１３０は、第２のメディアゲートウエイ５２０を割り当て、類似の非互換性のノード１０３と１０４の各々にサービスを提供させる。割り当てられた第２のメディアゲートウエイ５２０は、ノード１０１−１０２のボコーダとノード１０３−１０４のボコーダ間の非互換性のデータ形式を変換するトランスレータを含むか、またはメディアゲートウエイ５２０に接続されて動作するアプリケーションプラットホームに含まれる適切なトランスレータを利用するかのいずれか一方を用いればよい。

他の実施例として、メディアゲートウエイ制御装置１３０は、通信装置１１３および１１４のような通信セッションの参加者のサブセットおよびそれらの関連するノード１０３、１０４が、第２のメディアゲートウエイ５２０に地理的に近接し、第１のメディアゲートウエイ１２０から地理的に遠く離れていることを判断できる。ノードの近接性は、ノードの２つ以上が同一のＩＰネットワークまたはサブネットワークにあることを決定するノードの各々のＩＰアドレスの比較により判断できる。次に、第２のメディアゲートウエイ
５２０は、ゲートウェイが同一のネットワークまたは関連したネットワーク（ルックアップ表によって算出できるように）にあるように選択できる。ノードの近接性は、ＳＩＰメッセージ内にあって、通信セッションの確立中通信装置１１１−１１４とノード１０１−１０４によって交換される「コンタクト」情報に基づいて算出することもできる。「コンタクト」情報は、その時に参加者の位置を識別するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）またはＩＰアドレスを含む。次に、ＵＲＬは、共通のテキスト文字列に関して調べ、および／またはＩＰアドレスは、共通ネットワークまたはサブネットワークに関して調べることもできる。次に、第２のメディアゲートウエイ５２０は、類似のＵＲＬまたはＩＰアドレスで選択されてもよい。次に、メディアゲートウエイ制御装置１３０は、第２のメディアゲートウエイ５２０を割り当て、離れている参加者のサブセットにサービスを提供させるので、その結果、ＩＰネットワーク１０６部を通過しなくてはならないパケット数を削減できる。例えば、「ディスパッチ呼び出しを配置する方法およびその装置」と題する米国特許出願番号第１０／１３７、１３７号（Ｕ．Ｓ．ｐａｔｅｎｔ ａｐｐｌｉｃａｔｉｏｎ ｎｏ．１０／１３７，１３７， ｅｎｔｉｔｌｅｄ ”Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｌａｃｉｎｇ ａ Ｄｉｓｐａｔｃｈ Ｃａｌｌ”）は、離れている参加者のサブセットにデータパケットを配信する方法を記載している。この出願は本発明の譲受人に譲渡されたものであり、その全体が引用により本明細書に組み込まれる。

通信システム５００において、通信装置１１１−１１４を含む通信セッションがセットアップされると、メディアゲートウエイ制御装置１３０は、ノード１０１、ノード１０２、およびメディアゲートウエイ５２０の各々にメディアゲートウエイ１２０のＩＰアドレス／ポートの組み合わせを割り当て、割り当てたアドレス／ポートの組み合わせをメディアゲートウエイ１２０に通知する。メディアゲートウエイ制御装置１３０は、対応するノードまたはメディアゲートウエイのＩＰアドレスおよびポートと、各割り当てられたメディアゲートウエイ１２０のアドレス／ポートの組み合わせの結合についても、メディアゲートウエイ１２０に通知する。メディアゲートウエイ５２０に関連するメディアゲートウエイ制御装置、すなわち第１のメディアゲートウエイ制御装置１３０または第２のメディアゲートウエイ制御装置５３０は、メディアゲートウエイ５２０のＩＰアドレス／ポートの組み合わせもノード１０３、ノード１０４、およびメディアゲートウエイ１２０の各々に割り当て、割り当てたアドレス／ポートの組み合わせをメディアゲートウエイ５２０に通知する。メディアゲートウエイ５２０に関連するメディアゲートウエイ制御装置は、対応するノードまたはメディアゲートウエイのＩＰアドレスおよびポートと、各割り当てられたメディアゲートウエイ５２０のアドレス／ポートの組み合わせの結合についてもメディアゲートウエイ５２０に通知する。

ＲＴＰデータパケットが、第１のメディアゲートウエイ１２０によって、ノード１０３および１０４を介して通信装置１１３および１１４の各々に送られるとき、パケットの単一のバージョンが、第１のメディアゲートウエイ１２０によって、第２のメディアゲートウエイ５２０に送られてもよい。メディアゲートウエイ５２０は、メディアゲートウエイ５２０のアドレス／ポートの組み合わせすなわちノード１０３および１０４向けに、受信したＲＴＰパケットの複写を各参加ノードへの送信用に作成し、複写したＲＴＰデータパケットを装置のそれぞれのノード１０３、１０４を介して各通信装置１１３、１１４に送る。

通信システム５００は、同じ非互換性を被っている複数のノードにサービスを提供するよう第２のメディアゲートウエイ５２０を割り当てることによって、非互換性のノードが、複数参加者通信セッションの一部としてＲＴＰフロア管理メッセージの交換に参加することを効率的に容易にしている。さらに、通信システム５００は、第２のメディアゲートウエイに近接した複数のノードにサービスを提供するよう第２のメディアゲートウエイ５
２０を割り当てることによって、ＩＰネットワーク１０６部を通過しなくてはならない多くのパケットを削減するので、その結果、ネットワーク１０６を介するＲＴＰフロア管理メッセージのより効率的な配信を提供できる。内在するネットワークおよび装置にトランスペアレントで、通信システムを構築するのに最小限のオーバーヘッドを課すフロア管理プロトコルの結果、効率的な高速フロア管理プロセスが提供される。

本発明をその特定の実施形態に関して特に示し、説明したが、当業者は、添付の請求項に記載されているような本発明の範囲を逸脱することなく、種々の変更がなされてもよく、また等価物をその構成要素の代わりに使用できることを理解するであろう。したがって、本明細書および添付の図面は、本発明の範囲を限定するよりもむしろ例証として考慮されるべきであり、そのような変更および置換はすべて、本発明の範囲に包含されるものとする。

利益、その他の効果、および問題解決策を特定の実施形態に関して上に説明した。しかし、そのような利益、効果、または問題解決策、ならびに任意の利益、効果、または問題解決策を発生させるかまたはより顕著にするあらゆる構成要素は、一部または全部の請求項の重要な、必要な、または不可欠な機能または構成要素として解釈されるべきでない。本明細書で使用する場合、用語「有する、含む、から成る（ｃｏｍｐｒｉｓｅｓ）」「有している、含んでいる、から成る（ｃｏｍｐｒｉｓｉｎｇ）」、またはその任意の変化形は、非排他的な包含物をカバーするものであり、構成要素の列挙を含むプロセス、方法、物品、または装置は、それらの構成要素のみを含むわけではなく、明示的に列挙されていないか、そのようなプロセス、方法、物品、または装置に固有の、他の要素も含み得るものとする。

本発明の実施形態による無線通信システムのブロック図。 先行技術の典型的なリアルタイムプロトコルデータパケットのビットマップ。 本発明の実施形態によるリアルタイムプロトコルデータパケットのビットマップ。 本発明の実施形態による複数参加者通信セッションにおけるフロア管理を提供する際に、図１の通信システムによって実行されるステップの論理流れ図。 本発明の他の実施形態による無線通信システムのブロック図。

Claims (21)

1. 複数の参加者を含む通信セッションにおける話者アービトレーションを提供する方法であって、
   リアルタイムプロトコル（ＲＴＰ）データパケットを組み立てるステップと、
   前記リアルタイムプロトコルデータパケットにヘッダ拡張子を加えるステップと、
   前記ヘッダ拡張子に話者アービトレーションコマンドを埋め込んでＲＴＰフロア管理メッセージを生成するステップと、
   から成る方法。
2. 通信セッションのフロアを確保する少なくとも１つの要求に対しリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを利用するステップと、通信セッションのフロアの確保を許可するステップと、通信セッションのフロアを確保する要求を否定するステップと、通信セッションのフロアの確保を放棄するステップと、ＲＴＰフロア管理メッセージの受理を肯定するステップと、をさらに含む、請求項１記載の方法。
3. 前記リアルタイムプロトコル（ＲＴＰ）フロア管理メッセージは、通信セッションのフロアの確保を許可するために利用されるとともに、前記複数の参加者の中の１人の参加者にフロアの確保を許可するために、インターネットプロトコル（ＩＰ）マルチキャストの使用により前記ＲＴＰフロア管理メッセージを複製するステップをさらに含む、請求項２記載の方法。
4. 複数の参加者を含む通信セッションにおける話者アービトレーションの方法であって、
   通信セッションのフロアを確保する要求を受理するステップと、
   前記フロアを確保する要求を有するリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを組み立てるステップと、
   前記ＲＴＰフロア管理メッセージを送信するステップと、から成る方法。
5. 前記リアルタイムプロトコル（ＲＴＰ）フロア管理メッセージが、第１のＲＴＰフロア管理メッセージを有するとともに、前記方法が、前記第１のＲＴＰフロア管理メッセージの送信に応答して、前記フロアを確保する要求を許可しない第２のＲＴＰフロア管理メッセージを受信するステップをさらに含む、請求項４記載の方法。
6. 前記リアルタイムプロトコル（ＲＴＰ）フロア管理メッセージが、第１のＲＴＰフロア管理メッセージを有するとともに、前記方法が、前記第１のＲＴＰフロア管理メッセージの送信に応答して、前記フロアを確保する要求を許可する第２のＲＴＰフロア管理メッセージを受信するステップをさらに含む、請求項４記載の方法。
7. フロアの確保を解除したい要望の指示を受信するステップと、
   フロアの管理を放棄する第３のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを組み立てるステップと、
   前記第３のＲＴＰフロア管理メッセージを送信するステップと、をさらに含む、請求項６記載の方法。
8. 複数の参加者と、前記複数の参加者に関連する複数のノードとを含む通信セッションにおける話者アービトレーションの方法であって、
   通信セッションの前記複数の参加者の中の１人の参加者から、通信セッションのフロアを確保する要求を有する第１のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを受信するステップと、
   フロアが利用可能かどうかを判断するステップと、
   フロアが利用可能な場合、前記フロアを確保する要求を許可する第２のＲＴＰフロア管理メッセージを送信するステップと、
   フロアが利用可能ではない場合、前記フロアを確保する要求を許可しない第３のＲＴＰフロア管理メッセージを送信するステップと、
   から成る方法。
9. 前記１人の参加者が第１の参加者から成るとともに、前記第２のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを送信するステップが、フロアが利用可能な場合、前記第１の参加者に前記フロアを確保する要求を許可する第２のＲＴＰフロア管理メッセージを、前記複数の参加者の各参加者に送信するステップを有する、請求項８記載の方法。
10. 前記第１のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを受信するステップが、前記通信セッションのフロアを確保する要求を有する第１のＲＴＰフロア管理メッセージを、通信セッションの前記複数の参加者の中の少なくとも２人の参加者の各々から受信するステップから成るとともに、前記第２のＲＴＰフロア管理メッセージを送信するステップが、
    フロアが利用可能な場合、前記少なくとも２人の参加者のうちのフロアを確保する要求を許可すべき第１の参加者を決定して被許可者となすステップと、
    前記被許可者に前記フロアを確保する要求を許可する第２のＲＴＰフロア管理メッセージを送信するステップと、
    から成る、請求項８記載の方法。
11. 前記第２のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージが前記被許可者をさらに識別するとともに、前記第２のＲＴＰフロア管理メッセージを送信するステップが、前記少なくとも２人の参加者の中の第２の参加者に、前記第２のリアルタイムプロトコル（ＲＴＰ）フロア管理メッセージの複写を送信するステップから成る、請求項１０記載の方法。
12. 前記複数のノードの内の第１のノードが、前記複数のノードの内の第２のノードおよび前記複数のノードの内の第３のノードの各々によって利用される第２のメッセージ形式と異なる第１のメッセージ形式を利用するかどうかを判断するステップと、
    第１のゲートウェイを割り当て、前記第１のノードからＲＴＰデータパケットを受信するステップと、
    各々前記第２のメッセージ形式を利用する前記第２のノードおよび前記第３のノードの判断に応答して、第２のゲートウェイを割り当て、前記第１のゲートウェイからのメッセージを受信し、その受信メッセージの複写を生成し、前記受信メッセージの複写を前記第２のノードおよび前記第３のノードの各々に送るステップと、
    をさらに含む請求項８記載の方法。
13. 第１のゲートウェイを割り当て、前記複数のノードの内の第１のノードからＲＴＰデータパケットを受信するステップと
    前記複数のノードの内の第２のノードおよび前記複数のノードの内の第３のノードが、第２のゲートウェイに近接しているかどうかを判断するステップと、
    前記第２のノードおよび前記第３のノードが前記第２のゲートウェイに近接しているという判断に応答して、前記第２のゲートウェイを割り当て、前記第１のゲートウェイからのメッセージを受信し、その受信メッセージの複写を生成し、前記受信メッセージの複写を前記第２のノードおよび前記第３のノードの各々に送るステップと、
    をさらに含む請求項８記載の方法。
14. 前記複数の参加者の中の２人の参加者が、話者アービトレーションサービスを明示的に
    提供する仲介のメディアゲートウエイなしで、リアルタイムプロトコル（ＲＴＰ）フロア管理メッセージを交換する、請求項８記載の方法。
15. 複数の参加者と、前記複数の参加者に関連する複数のノードとを含む通信セッションのフロア管理を提供する装置であって、リアルタイムプロトコル（ＲＴＰ）データパケットを組み立て、前記ＲＴＰデータパケットにヘッダ拡張子を加え、前記ヘッダ拡張子に話者アービトレーションコマンドを埋め込んでＲＴＰフロア管理メッセージを生成する信号処理装置を備えたゲートウェイを有する装置。
16. フロアを要求する前記複数の参加者の中にから通信セッションのフロアを許可されるべき参加者を選ぶアービトレーションアルゴリズムを実行するアービトレーションロジックをさらに有する、請求項１５記載の装置。
17. 前記ゲートウェイが、
    リアルタイムプロトコル（ＲＴＰ）データパケットを受信する手段と、
    前記受信したＲＴＰデータパケットの１つまたは２つ以上の複写を作成する手段と、
    前記受信したＲＴＰデータパケットの１つまたは２つ以上の複写を送信する手段と、
    をさらに有する、請求項１５記載の装置。
18. 前記ゲートウェイが、複数のゲートウエイルーティングアドレスを通信セッションにさらに割り当てるとともに、前記装置が、前記複数のゲートウエイルーティングアドレスの中の１つのゲートウエイルーティングアドレスを前記複数の関連するノードの各ノードに割り当てる前記ゲートウェイに接続された制御装置をさらに有する、請求項１７記載の装置。
19. 前記ゲートウェイが第１のゲートウェイを有するとともに、前記ゲートウエイルーティングアドレスが第１のゲートウエイルーティングアドレスを有し、前記制御装置は、前記複数のノードの内の第１のノードが、前記複数のノードの内の第２のノードおよび前記複数のノードの内の第３のノードの各々によって利用される第２のメッセージ形式と異なる第１のメッセージ形式を利用することをさらに決定し、前記制御装置は、各々第２のメッセージ形式を利用する前記第２のノードおよび前記第３のノードの決定に応答して、第２のゲートウェイを割り当て、前記第１のゲートウェイからのメッセージを受信し、その受信メッセージの複写を生成し、前記受信メッセージの複写を前記第２のノードおよび前記第３のノードの各々に送る、請求項１８記載の装置。
20. 前記ゲートウェイが第１のゲートウェイを有するとともに、前記ゲートウエイルーティングアドレスが第１のゲートウエイルーティングアドレスを有し、前記制御装置は、前記複数のノードの内の第１のノードおよび前記複数のノードの内の第２のノードが第２のゲートウェイに近接していることをさらに判断し、前記制御装置は、前記第１のノードおよび前記第２のノードが前記第２のゲートウェイに近接しているという判断に応答して、前記第２のゲートウェイを割り当て、前記第１のゲートウェイからのメッセージを受信し、その受信メッセージの複写を生成し、前記受信メッセージの複写を前記第１のノードおよび前記第２のノードの各々に送る、請求項１８記載の装置。
21. 前記複数のノードの内の第１のノードが前記複数のノードの内の第２のノードによって利用される第２のメッセージ形式と異なる第１のメッセージ形式に準じて動作することを決定する手段と、
    メッセージを、前記第１のメッセージ形式から前記第２のメッセージ形式に変換する手段と、
    前記第１のノードと前記第２のノード間で交換されたメッセージを変換するよう、前記
    変換手段を割り当てる手段と、
    をさらに有する、請求項１５記載の装置。

Images