JP2006512857A

JP2006512857A - エンド・ポイント間のセッションを制御および管理すること

Info

Publication number: JP2006512857A
Application number: JP2004565604A
Authority: JP
Inventors: ケラー、マシュー; ジェイ．リリー、ロス; イー．マティス、ジェームス; ジー．ニューバーグ、ドナルド
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2002-12-31
Filing date: 2003-12-18
Publication date: 2006-04-13
Anticipated expiration: 2023-12-18
Also published as: TWI242357B; WO2004062176A2; US20040133683A1; JP4391423B2; AU2003301156A1; CA2511937A1; CA2511937C; TW200420101A; US8412829B2; EP1584043A2; EP1584043A4; AU2003301156A8; IL169234A; US7366780B2; US20080168172A1; WO2004062176A3

Abstract

論理エンティティおよびその物理対応物をそれぞれ含む複数のエンド・ポイント（２４０，２４２，２４６）を有する通信システムにおいて、少なくとも二つのエンド・ポイント間のセッションを制御および管理するシステム。このシステムは、登録マネージャ（２０２）、アプリケーション層ルータ（２０４）、セッション・コントローラ（２０６）、グループ・データベース・マネージャ（２０８）、および少なくとも一つのグループ・エンティティ（２１０）を含む。

Description

本発明は、一般的に、通信システムにおける少なくとも二つのエンド・ポイント間でグループ指向セッションを可能にする装置および方法に関わる。
（関連出願の引用）
本発明は、モトローラ社によって本願とともに一般的に所有される以下の米国出願に関わる。

ニューバーグ（Newberg ）らによる“通信システムにおいてマルチキャスト・アドレスのプールを管理しアドレスを割り当てる方法（Methods for Managing a Pool of Multicast Addresses and Allocating Addresses in a Communications System）”と題された２００２年１２月３１日に出願の米国特許出願番号第１０／３３４，６３５号（代理人整理番号ＣＭ０５６６６Ｇ）、
リリー（Lillie）らによる“通信システムにおいて個別指向セッションを制御および管理する装置および方法（Apparatus and Method for Controlling and Managing Individual Directed Sessions in a Communications System ）”と題された２００２年１２月３１日に出願の米国特許出願番号第１０／３３４，５２３号（代理人整理番号ＣＭ０５６６５Ｇ）、
ニューバーグ（Newberg ）らによる“エンド・ポイントをグループに加入させ、加入したエンド・ポイントに対して共通の通信性能を決定する方法（Methods for Affiliating Endpoints with a Group and Determining Common Communication Capabilities for the Affiliated Endpoints ）”と題された２００２年１２月３１日に出願された米国特許出願番号第１０／３３４，４３９号（代理人整理番号ＣＭ０５６３８Ｇ）、
リリー（Lillie）らによる“グループ通信のための方法およびシステム（Method and System for Group Communication ）”と題された２００２年１２月３１日に出願された米国特許出願番号第１０／３３４，５２１号（代理人整理番号ＣＭ０５１００Ｇ）。

マルチメディアおよびグループ通信は電気通信の重要な特徴であり、その需要は増加し続けている。例えば、１９９６年付けの連邦通信委員会（ＦＣＣ：Federal Communications Committee）への公共安全無線諮問委員会の最終報告書では、マルチメディアに対する通信リソースの重要なニーズを説明している。その後、ＦＣＣは、１９９８年に公共安全広帯域のためのスペクトルを含む７６４ＭＨｚ周波数に対する帯域プランを確立した。更に、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ：Internet Engineering Task Force ）は、マルチメディア通信で使用するよう設計された一式のプロトコルを開発した。これらのプロトコルは、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol ）、セッション・アナウンスメント・プロトコル（ＳＡＰ：Session Announcement Protocol ）、およびセッション記述プロトコル（ＳＤＰ：Session Description Protocol）を含む。

公式標準として１９９９年初頭に認可されて以来、ＳＩＰは、インターネット上で通信サービスをシグナリングすることに関して強大な市場支持を得ている。ＳＩＰデスクトップ電話機、ＳＩＰテレフォニー・サーバ、およびＳＩＰアプリケーションを実行するパーソナルコンピュータ（ＰＣ：Personal Computer ）装置を含むがこれらには限定されない多数の製品がＳＩＰ標準を組み込んでいる。ＳＩＰは、ハイパーテキスト転送プロトコル（ＨＴＴＰ：Hyper Text Transfer Protocol）および簡易メール転送プロトコル（ＳＭＴＰ：Simple Mail Transfer Protocol ）に類似するテキストベースのシグナリング・トランザクション・プロトコルであり、開放型システム間相互接続（ＯＳＩ：Open System Interconnection ）通信モデルのアプリケーション層において機能する。ＳＩＰメッセージは、通信ネットワークにおけるユーザ（本願では呼出側とも称される）間で声、ビデオ、およびチャットのような対話型通信セッションを制御するために用いられる。各ユーザは、ネットワークに接続される通信装置（本願では端末装置とも称される）と典型的には関連付けられる。

ＳＩＰは、メディア・セッションを制御し、開始側エンド・ポイントと、一つの受信側エンド・ポイントまたは小さなグループの受信側エンド・ポイントとの間でメディア・セッションを確立するよう設計される。しかしながら、ＳＩＰは、開始側エンド・ポイントと大きなグループの受信側エンド・ポイントとの間でメディア・セッションを確立するには容易に拡張可能でない。これは、標準ＳＩＰにおいて、開始側エンド・ポイントと所与のグループ中の各受信側エンド・ポイントとの間で三つのメッセージ（ＩＮＶＩＴＥ／ＯＫ／ＡＣＫ）が交換されなくてはならないからである。グループが特に大きい場合、過剰メッセージングは、例えば、公共安全の領域におけるような時間依存通信には望ましくない帯域幅およびタイミングの問題を引き起こす。

グループ通信のための公知のシステムは、グループ通信を可能にするために標準ＳＩＰを用いることを試みている。このために、同システムは、図１に示すサーバ中心のアーキテクチャ１００に従って呼制御アーキテクチャを実行する。アーキテクチャ１００は、プッシュ・ツー・トーク（ＰＴＴ：Push-To-Talk）通信システムに含まれてもよい。アーキテクチャ１００は、エンド・ポイント１０４と、エンド・ポイント１１２、１１４、および１１６を備えるグループ１１０とのシグナリング経路に通信可能に接続されるＰＴＴサーバのようなサービス指定サーバ１０２を含む。

この枠組みを用いた場合、グループ通信は、エンド・ポイント１１２、１１４、および１１６にとって全ての呼制御シグナリングのターゲットとして知られるＰＴＴサーバ１０２によってサポートされている。セッションをセットアップするために開始側エンド・ポイントは、インターネット・プロトコル（ＩＰ：Internet Protocol ）アドレスを用いてＰＴＴサーバ１０２にセッション・リクエストをターゲットしなくてはならない。具体的には、セッション・リクエストにおいて利用される呼制御シグナリングが何らかの方法でグループを識別する一方で、ＰＴＴサーバ１０２へのルーティングがドメイン名システム（ＤＭＳ：Domain Name System）ルックアップを実施し、ネットワーク層ＩＰプロトコルを用いて実現される。このアプローチ法は、グループ通信を特定のサーバと結び付けることで、負荷平衡および故障の回復を実施するシステムの性能を制限し、開始側エンド・ポイントにグループ名だけでなく適切なサーバのＩＰアドレスを知ることも要求することで更なる負担を課すため、制限がある。

更に、既存のグループ通信アプローチ法では、明確なＳＩＰコール・レッグが各グループのメンバーをセッションに参加させるために使用されなくてはならないため拡張性およびパフォーマンスが制限されている。従って、グループのメンバーの数が増加すると、セッション・セットアップが完了する前により多くの三方向シグナリング交換を共有のワイヤ・ラインおよびワイヤレス・リンク上で実施しなくてはならない。より大きなグループについて直列化遅延は、特定のシステム、特に、公共安全ディスパッチ・システムの許容可能な範囲を超えて呼セットアップ時間を増加させる。

グループ通信に関して上述の制限された方法でＳＩＰシグナリングを用いるシステムの一つの実施例は、“既存の通信システムにおいてグループ通信サービスに参加する方法および装置（METHOD AND APPARATUS FOR PARTICIPATING IN GROUP COMMUNICATION SERVICES IN AN EXISTING COMMUNICATION SYSTEM）”と題されたＷＯ０１６７６７４Ａ２（０９／５１８７７６）に開示されている。同明細書は、ボイス・オーバーＩＰ（ＶｏＩＰ：Voice over IP ）グループ通信を提供するためにパケット・データ・システムに追加され得るＰＴＴサーバを説明する。端末がネット（エンド・ポイントのグループ）と通信することを望むとき、端末はＤＮＳを用いて適当なトップ・レベル・サーバのＩＰアドレスを決定してインターネット・ネットワーク・アドレスにＳＩＰサーバ・アドレスをリゾルブし、該サーバにＳＩＰＩＮＶＩＴＥを送出しネットとのセッションをリクエストする。該サーバは、呼制御シグナリング、話者アービトレーション・シグナリング、およびメディアのターゲットでもある。更に、ポイント・ツー・ポイントＳＩＰシグナリングだけが使用される。

従って、どの特定の端末を使用しているかに関わらずターゲット名およびドメインのみに基づいてユーザにセッションを開始させることを可能にするようＳＩＰのアプリケーション層ルーティング制御を利用し、更に、より大きなグループのユーザに対してより大きな拡張性およびより高速の呼セットアップを可能にする特徴を含む、呼制御アーキテクチャが必要である。

本発明の好ましい実施形態を添付の図面を参照して、一例として以下に説明する。
例示を簡単および明確にするために図面に示される要素が必ずしも一定の比率で描かれていないことは理解されるであろう。例えば、幾つかの要素の寸法は相対的に誇張されている。更に、適当と考えられる場合には、同一の参照番号が図面間の対応する要素を示すために繰り返されている。

図２は、本発明の好ましい実施形態による、通信システムにおける少なくとも二つのエンド・ポイント間で通信を可能にする幾つかのエンティティおよびその通信経路を備える呼制御アーキテクチャ２００を例示する。各エンド・ポイントは、典型的には、ユーザのような論理エンティティと、端末のような物理対応物とを備える。黒い実線で接続されるエンティティは、トランザクション・プロトコルまたはブロードキャスト・プトロコルを用いて通信される。好ましいトランザクション・プロトコルはＳＩＰであり、好ましいブロードチャスト・プロトコルはＳＡＰである。破線で接続される他のエンティティは、当該技術分野において公知の適当なプロトコルを用いて通信される。アーキテクチャ２００は、公共安全ディスパッチ・システムのように時間が重要な通信システムにとって理想的である。

アーキテクチャ２００は、少なくとも二つのエンド・ポイント（例えば、エンド・ポイント２４０および２４２）間でグループ通信を可能にするために、セッション・コントローラ２０６、グループ・データベース・マネージャ２０８、およびアプリケーション層において命名されてアドレス指定可能な少なくとも一つのグループ・エンティティ２１０を備える。アプリケーション層ルーティングを更に容易化するために、アーキテクチャ２００は、登録マネージャ２０２およびＳＩＰプロキシであることが好ましいアプリケーション層ルータ２０４を備えることが好ましい。最後に、アーキテクチャ２００は、グループ・エンティティ・マネージャ２１２、パラメータ・リゾルバ２１４、少なくとも一つの個別プロキシ２１６、個別プロキシ・マネージャ２１８、マルチキャスト・アドレス・マネージャ２２０、ポリシー・マネージャ２２４、フロア・コントローラ２３０、メディア・マネージャ２２６、および、帯域幅マネージャ２３２を含むことが好ましい。アーキテクチャ２００は、本発明を例示する目的のために簡略化されている。しかしながら、当業者であれば、アーキテクチャ２００は、システムの大きさに応じて例示のエンティティそれぞれを複数個含み得ることに気付くであろう。

アーキテクチャ２００は、基本となるネットワークおよびエア・インタフェースとは無関係に構成され、ネットワーク指定の機能性に関しては帯域幅マネージャ２３２のようなエンティティに依存する。

図３に示すように、アーキテクチャ２００は、セッション・シグナリング層３０４、セッション・サービス層３０６、および、無線アクセス・ネットワーク（ＲＡＮ：Radio Access Network）層３０８の三層に要約される。セッション・シグナリング層３０４は、セッションを開始、変更、および、終了するために組み合わされて使用されるＳＩＰ、ＳＡＰ、および、ＳＤＰのようなセッション制御シグナリングを終了する。セッション・シグナリング層３０４は、更に、セッション・サービス層３０６に対してリクエストを作成し、セッション・サービス層３０６から帯域幅の不足のようなイベントを受信する。セッション・サービス層３０６は、優先順位および優先的使用のため、ならびに重要なユーザなどの特徴のためにセッション・インターアクションのようなセッション・サービスを提供する。セッション・サービス層３０６は、更に、ユーザまたはグループが特定のタイプの呼を発するか、あるいは、特定の量の帯域幅を使用することを可能にするなどのシステム・ポリシーを施行し、更に、エンド・ポイント３０２のようなエンド・ポイントにフロア制御またはメディア管理サービス（例えば、トランスコーディング）のようなイン・セッション・サービスを直接的に提供する。ＲＡＮ層３０８は、ＳＡＭ（拡張可能な適応変調（Scalable Adaptive Modulation））３１０および無線ローカル・エリア・ネットワーク（ＷＬＡＮ：Wireless Local Area Network ）３１２などの基本となるワイヤ・ラインおよびワイヤレス・ネットワークの実行を認識し、セッション・サービス層３０６をサポートするためのネットワーク指定の機能性を提供する。この機能性は、様々なワイヤードおよびワイヤレス・リンクに対する帯域幅管理、および、システムにおける端末の位置管理を含む。

階層図３００は、各層が他の層とは独立して変更される点で有利である。例えば、別の呼制御プロトコルが望まれる場合に、セッション・シグナリング層３０４は、他の層に影響を与えることなく変更される。更に、このように階層的に扱うことにより、アーキテクチャ２００はセッション・サービスまたはセッション・シグナリングに影響を与えることなく様々なエア・インタフェースおよびモビリティ・スキームをサポートすることができる。

図４は、アーキテクチャ２００の階層図４００並びに様々な層へのアーキテクチャ２００の構成要素の割り当てを示す。登録マネージャ２０２、グループ・データベース・マネージャ２０８、グループ・エンティティ２１０、および個別プロキシ２１６は、セッション・シグナリング層４０２に割り当てられる。セッション・コントローラ２０６、メディア・マネージャ２２６、およびフロア・コントローラ２３０は、セッション・サービス層４０４に割り当てられ、帯域幅マネージャ２３２はＲＡＮ層４０６に割り当てられる。以下により詳細に説明するように、セッション・コントローラ２０６と、個別プロキシ２１６、グループ・エンティティ２１０、および帯域幅マネージャ２３２との間のインタフェースは、異なるＲＡＮまたは異なるセッション・シグナリング・プロトコルを使用するシステムに適応するためのフレキシビリティを提供する。更に、階層的に扱うことにより、エンド・ポイントの観点から標準ＳＩＰトランザクション・モデルを維持し、それにより、ディスパッチおよび非ディスパッチ・エンド・ポイントの両方との相互動作を簡略化し、将来的なＳＩＰ標準および製品のより良い活用を可能にする。

アーキテクチャ２００は、確認と未確認の二つのタイプのセッション・セットアップ方法をサポートすることが好ましい。未確認セッション・セットアップでは、エンド・ポイントへのセッション通知は肯定応答されず、大きなグループに対してより良い拡張性を提供する。従って、全ての未確認セッション・セットアップは、人間の介入なく、且つ、セッションを断るまたはどの端末を使用することを望むかを示す機会を目標とするユーザに与えることなく目標とする端末によって自動的に受け入れられることが好ましい。未確認セッション・セットアップは、例えば、基幹グループ・ディスパッチ・セッションに対して使用されることが好ましく、これは、これらのセッションが典型的には数百ミリ秒以内で作動される必要があるからであり、それによりセッション通知はグループにブロードキャストされる。

確認セッション・セットアップは、応答を全ての目標とするユーザまたは端末から期待するか要求するとき使用される。このタイプのセッション・セットアップは、例えば、セッション開始側が、目標とするエンド・ポイントが実際にセッション中であること、ユーザがいる端末にだけセッションが向かうこと、または、目標とするエンド・ポイントがメディアを受信する準備ができていることを確実にすることを望むときに使用される。セッション・セットアップは確認および未確認の組み合わせでもよく、このとき、セッション招待の大部分が理想的には未確認であり、数個の戦略的なまたは必要なユーザだけが確認セッション招待を受信する。

図２に示されるエンティティそれぞれの好ましい実施形態は、その好ましい機能性を含み以下に説明される。各エンティティは、通信システムにおいて情報を受信する受信部と、通信ネットワークにおいて情報を送信する送信部と、様々な機能を実施することをエンティティに可能にさせるプロセッサとを備えることが好ましい。

システムにおける各エンド・ポイント、例えば、エンド・ポイント２４０、２４２、および、２４６は、固有のユーザおよび端末バインディングを備え、各端末はフロア・コントローラ２３０との通信を可能にするためのＰＴＴ機能の最小性能を有し、グループに加入することができ、ＩＰマルチキャストを介してメディアおよび制御（ＳＡＰ）を交換することができるディスパッチ端末であることが好ましい。反対に、非ディスパッチ端末は、上述の三つの機能を一つ以上実施することができない。エンド・ポイントは、好ましくは、ＳＩＰユーザ・エージェント・クライアント（ＵＡＣ：User Agent Client ）およびＳＩＰユーザ・エージェント・サーバ（ＵＡＳ：User Agent Sever）の両方を備え、グループ指向または個別指向セッションのいずれか一方をセットアップ、変更、および終了するためにエンド・ポイントが通信システムと対話することを可能にし、このとき、グループ指向セッションはグループへの招待であり、個別指向セッションは少なくとも一つの個別エンド・ポイント、例えば、ポイント・ツー・ポイントへの招待である。エンド・ポイントは、発呼または着呼のために、最初システムに登録されなくてはならない。ＳＩＰシグナリングが全てのセッション制御シグナリングに好ましくは利用されるためＳＩＰＲＥＧＩＳＴＥＲ方法が使用され、全てのＳＩＰＲＥＧＩＳＴＥＲリクエストが登録マネージャ２０２に好ましくは送出される。エンド・ポイントがグループのメンバーになることを望む場合、本発明によるＡＦＦＩＬＩＡＴＥ方法を用いてグループに加入しなくてはならず、全ての加入リクエストがグループ・データベース・マネージャ２０８に好ましくは送出される。

エンド・ポイントは、グループのコンテキスト内でセッションの追加および除去をエンド・ポイントに知らせるためにＳＡＰアナウンスメントを受信するよう構成されることが好ましく、セッション中、エンド・ポイントは、特定のセッションのメディア・ストリームに対するソースを制御する目的でフロア・コントローラ２０３と直接的に相互作用することが好ましい。フロア・コントローラとの相互作用に使用されるプロトコルは、ＳＩＰおよびＳＡＰセッション・シグナリングの一部としてＳＤＰで特定される。

セッション・コントローラ２０６に注意を向けると、例えば、マルチゾーン・システムにおいて多数のセッション・コントローラが存在してもよく、セッション・コントローラは、無線およびワイヤ・ライン帯域幅などのシステム・リソース、エンド・ポイントが別のセッションに現在参加しているか否かなどのエンド・ポイント・リソース、および目標とするエンド・ポイントの性能のような要素に応じて、全てのセッションに対する状態を制御領域内に維持する。セッション・コントローラ２０６は、リクエストされたマルチメディア・セッションが確立されるか否かを決定する責任を担い、帯域幅マネージャ２３２と協働で帯域幅を確保して所与のセッションに対して適当なサービスの質（ＱｏＳ：Quality of Service）の確保を行う。セッション・コントローラ２０６は、パラメータ・リゾルバ２１４とも協働して受け入れられたセッションの間に使用可能な対応する組のセッション・パラメータを決定する。

セッション・コントローラ２０６は、全てのセッションおよび全てのセッションへの参加者を認知可能なシステムの唯一のエンティティであることが好ましい。従って、重要なユーザのような情報を用いて、重要なユーザが有効か否かを判断することが好ましい。それにより、重要なユーザが有効でない場合、セッションはキューに入れられる。更に、セッション・コントローラ２０６は、優先順位の低いセッションから重要なユーザを引き出して該ユーザを別の優先順位の高いセッションに配置すると判断してもよい。更に、セッション・コントローラ２０６は、グループ・データベース・マネージャ２０８または登録マネージャ２０２のいずれか一方からエンド・ポイントが幾つのセッションを同時にサポートすることができ、従って、セットアップされているセッションに入れるか否かを認識していることが好ましい。

グループ・エンティティ２１０に注意を向けると、それは、ＳＩＰＵＡＣ、ＳＩＰＵＡＳ、および任意にはＳＡＰセッション・ディレクトリを単一のエンティティに組み合わせる専門ＳＩＰエンティティであることが好ましい。ＳＩＰＵＡＣとＳＩＰＵＡＳの機能性により、グループ通信に対する単点の制御が可能となり、ＳＡＰディレクトリの機能性は拡張性およびパフォーマンスを向上させる。

各グループ・エンティティは、エンド・ポイントがグループとのセッションをセットアップするためにグループの関連するグループ・エンティティにＳＩＰシグナリングを送出することができるように、アプリケーション層において命名されてアドレス指定可能にされる。この特徴は、図１に関連して説明された従来のサーバ・モデルから本発明を区別し、グループ通信に関して責任を担うサーバはネットワーク層と通信される。

グループ・エンティティ２１０は、セッション・リクエストを受信すると、グループ・データベース・マネージャ２０８からのグループ加入情報に基づいてセッションに引き入れるエンド・ポイントの組を決定し、セッションをセットアップするリクエストとともにグループ・メンバーに対する全てのリクエストされるセッション・パラメータおよび性能をセッション・コントローラ２０６に送出するよう構成されることが好ましい。セッション・コントローラ２０６がそのリクエストを許可すると、グループ・エンティティ２１０は確認セッション・セットアップについてはＳＩＰＩＮＶＩＴＥを介して、または、未確認セッション・セットアップについてはマルチキャストＳＡＰアナウンスメントのようなセッション・アナウンスメント・プロトコルを介して加入されたエンド・ポイントにセッション・セットアップをシグナリングする。

個別プロキシ２１６に注意を向けると、それは、少なくとも二つのエンド・ポイント間で個別指向セッション（例えば、ポイント・ツー・ポイント）がセットアップされるときに基本となるセッション・コントローラ２０６にアクセスすることを可能にする制御のシグナリング点を表す「ステートフル」ＳＩＰプロキシであることが好ましい。各個別プロキシ２１６は、リクエストされたセッションに成り代わって個別プロキシ・マネージャ２１８によってインスタンス作成され、セッションに等しいライフ・サイクルを有する。個別プロキシ２１６は、基本となるセッション・コントローラ２０６によって取り扱われるよう全てのセッション制御シグナリングが個別プロキシ２１６を通ることを確実にするために個別指向セッションのＳＩＰルートの組に自身を挿入しなくてはならない。残りのシステムにとって、特に、エンド・ポイントにとって最も重要なことは、個別プロキシ２１６がＳＤＰを変更するかセッションを進めることができないことを示したとしてもＳＩＰシグナリングが端末相互間で送出されるようにみえることである。これにより、ＳＩＰ標準への順守、および、可能性として、標準ＳＩＰ装置とのよりよい互換性が可能となる。

動作の間、個別プロキシ２１６は、開始側エンド・ポイントのＵＡＣからのＳＩＰＩＮＶＩＴＥメッセージを遮断し、ＩＮＶＩＴＥで特定される宛先およびシステム・ポリシー情報に基づいてセッションにどのエンド・ポイントを関わらせるかを好ましくは決定する。ユーザがその全ての端末において呼び出される、その移動端末において呼び出される、あるいは、ＳＩＰセッション・セットアップ・リクエストで特定された端末でだけ呼び出されることを異なるポリシーが特定する場合もある。一旦エンド・ポイントのリストが選択されると、個別プロキシ２１６がセッションに有用な性能の優先的なリストを決定することが好ましい。この情報は、リクエストされたセッション参加者のリストとともにセッション・コントローラ２０６に送出される。セッションが与えられると、個別プロキシ２１６は全ての意図するエンド・ポイントに対してＳＩＰセッションＩＮＶＩＴＥメッセージを送出し、セッションがセットアップされる。更に、個別プロキシ２１６は、セッション中のエンド・ポイントに不可視となるようＳＩＰＦＲＯＭヘッダを自身のアドレスではなくセッション開始側のアドレスで充填する。

上述したとおり、全ての個別指向セッション・リクエストは、セッションのトラフィックを取り扱うために必要なシステム・リソース、エンド・ポイント・リソース、および、性能の有効性、または、認証、承認、およびアクセスポリシーのような他のパラメータを含む要素に応じてセッションが確立されるか拒絶されるかを決定するためにセッション・コントローラ２０６と相互作用する個別プロキシ２１６によって遮断される。個別プロキシ２１６は、ＳＩＰリクエストのペイロードによって説明されるように、リクエストされたセッションに関する情報をセッション・コントローラ２０６に送出する。この情報は、通常、ＳＤＰパケットの形態にある。セッション・コントローラ２０６とのこの相互作用により、個別プロキシ２１６は、意図する受信側エンド・ポイントにリクエストをルーティングし、適当な応答をセッション開始側に戻す。個別プロキシ２１６とセッション・コントローラ２０６との相互作用は、ＩＰＣ（プロセス間通信（Inter Process Communications））メッセージング、ＲＰＣメッセージング、ＣＯＲＢＡ、ＲＭＩ、または、専用プロセス間通信手段のような幾つかの従来の機構のいずれを介しても行われる。

基本となるセッション・コントローラ２０６がセッションを進めること、即ち、リクエストされたセッションを取り扱うために必要なシステム・リソースが有効であることを個別プロキシ２１６に知らせると、個別プロキシ２１６は、更新されたセッション・パラメータの決定（利用可能な帯域幅、ポリシー等に基づく）をセッション・コントローラ２０６に実行させるようＳＤＰを書き換えること以外では正常なＳＩＰルーティング・プロキシと同一に機能することが好ましい。これらの更新されたパラメータは、正常なＳＩＰトランザクションを用いて開始側エンド・ポイントおよび目標とするエンド・ポイントに戻されるが、どちらのエンド・ポイントもセッション交渉を第三者が制御し始めたことを知らない。リクエストされたセッションにリソースが現在利用可能でない場合、または、中断することができない別のセッションにエンド・ポイントの一つが現在いるとセッション・コントローラ２０６が判断した場合、セッション・コントローラ２０６は、セッション・リクエストを拒絶するか、あるいはキューに入れるという適当なＳＩＰ応答で開始側エンド・ポイントに応じるよう個別プロキシ２１６に指示する。

セッション・コントローラ２０６は、接続中にネットワーク状態が変化した場合に、または、どちらかのパーティが別のセッションに引き入れられる必要がある場合に、いずれかのエンド・ポイントからのどのリクエストにも独立して何時でもエンド・ポイント間のセッションを終了するよう個別プロキシ２１６に指示できることが好ましい。このとき、個別プロキシ２１６は、エンド・ポイント間で確立される制御ダイアログの一部として現れるようフォーマット化される対応するＳＩＰＢＹＥリクエストを各エンド・ポイントに送出する。上述の機能を実施するために、個別プロキシ２１６は、セッション開始側の開始ルート・セットに存在するか、標準ＳＩＰルーティング規則を通じて、プロキシが自身を例えば、ＳＩＰのＲＥＣＯＲＤ−ＲＯＵＴＥヘッダの適当な使用によりダイアログのルート・セットに追加しなくてはならない。これにより、いずれかのエンド・ポイントからの全ての将来的なＳＩＰリクエストが、補完的なＳＩＰＲＯＵＴＥヘッダの使用により個別プロキシ２１６を通じてルーティングされることが保証される。この標準機構により、ネットワーク・リソースの割り当てに可能性として影響を及ぼし得る全ての将来的なＳＩＰリクエストは、基本となるセッション・コントローラ２０６によって検査されるよう個別プロキシ２１６を通過する。

パラメータ・リゾルバ２１４に注意を向けると、それは、所与のグループに加入されたエンド・ポイントに共通の少なくとも一組の通信性能を確立するよう構成される。これらの性能は、オーディオ・コーデック、ビデオ・コーデック、画面サイズ、全二重、マルチキャストに対するサポートなどを含む。所与のグループに対する一組のグループ性能がリゾルブされると、それは、該所与のグループを伴うセッションの対応するセッション・パラメータを決定する際に、将来的に使用するためにデータベースに好ましくは保存される。

図５は、特定のグループに対して一組の共通の通信性能をパラメータ・リゾルバ２１４に生成させる、本発明による方法５００を示す。プロセスは、エンド・ポイント登録、加入リクエスト、プロセスを実施するための明示的なリクエスト、または、他の手段を含む幾つかのイベントによってステップ５０２においてトリガされる。ステップ５０４において、パラメータ・リゾルバ２１４は好ましくは適当なデータベースからグループに対するユーザ・リストを引き出し、ステップ５０６において、パラメータ・リゾルバ２１４は好ましくは適当なデータベースからユーザの端末それぞれに対する性能を引き出す。ステップ５０８において、パラメータ・リゾルバ２１４は、ユーザの端末の少なくとも部分的な組に共通の少なくとも一組の通信性能が存在するか否かを決定する。その決定が肯定された場合、ステップ５１０においてパラメータ・リゾルバ２１４は共通の組を生成し、ステップ５１２において、グループ・メンバー間の受け入れられたセッションに対する対応する組のセッション・パラメータを決定するために、当該共通の組を例えば、セッション・コントローラ２０６またはグループ・データベース・マネージャ（２０８）による将来的な使用のために適当なデータベースに保存する。ステップ５０８における決定が否定された場合、ステップ５１４においてパラメータ・リゾルバ２１４は、エラー状態を好ましくは生成する。エラー状態に対する一つの可能な解決策は、共通の組のセッション・パラメータが形成され得るようグループから重要でないユーザを除去することである。

パラメータ・リゾルバ２１４は、要求されるメディアまたは任意のメディアに対して方法５００のステップを実施してもよい。更に、パラメータ・リゾルバ２１４は、少なくとも一組の共通の性能が生成されるか否かを決定するステップ５０８をトランスコーディングまたはソフトウェアのダウンロードに応じて実施してもよい。トランスコーディングが実行可能である場合、共通の性能およびトランスコーディング・パラメータは、データベースに保存されることが好ましい。ソフトウェアのダウンロードが実行可能な場合、共通の性能がデータベースに保存されることが好ましく、適当なソフトウェアは直ぐにダウンロードされるか呼セットアップ時にダウンロードされるようフラグが付けられる。

一組の共通の性能が上述の有効な手段のいずれかによってグループ全体にわたってリゾルブされると、これらのパラメータはデータベースに記憶される。さもなければ、方法５００は、グループ・メンバーの一つ以上の部分的な組に対して一組（または、数組）の共通の性能を生成するように実施される。その後、セッション・パラメータが、呼セットアップ時等にリクエストされると、プロセスは、ユーザ・リクエスト、システム・ポリシー、呼の種類、帯域幅の利用可能性、コンテキスト（例えば、緊急）などに基づいてデータベースにおける可能な組から「最適な」組のパラメータを選ぶ。一旦共通性能データベースが確立されると、共通パラメータは、プロセス間のシグナリングの量を減少させるために呼セットアップ時に呼プロセス機能によって、または、加入時に加入機能によって分散される。更に、これらのパラメータは、明示的記述（例えば、オーディオ＝ＩＭＢＥ、ビットレート＝４．４ｋｂｐｓ）によって、または所定の論理セット（例えば、Ａ＝低速オーディオのみ、Ｂ＝高速オーディオのみ、Ｃ＝低速オーディオ＋低速ビデオ）によって表される。

パラメータ・リゾルバ２１４が方法５００を実施する、本発明による特定のシステムの実行を例示するバウンス・チャートを以下に示す。この実行は、エンド・ポイント１、エンド・ポイント２、および、エンド・ポイント３で登録され、グループ１に加入される三人のユーザ、登録マネージャ（２０２）、グループ（データベース）マネージャ（２０８）、および、パラメータ・リゾルバ（２１４）を含む、アーキテクチャ２００（図２）におけるエンティティによって実施される以下に挙げる七つの機能的ステップを含む。

この実行のステップ１乃至７は以下の通りである。
１．パワーアップの際、グループ加入を追跡し管理するグループ・マネージャは全てのエンド・ポイントの登録の通知を受信するよう登録マネージャに登録される。
２．パワーアップされると、エンド・ポイントは、その性能（例えば、コーデック、スクリーン分解能など）を登録マネージャに登録し、新しいエンド・ポイントそれぞれの存在とその性能がグループ・マネージャに通知される。これらのエンド・ポイントはどのグループにもまだ加入されていないため、この時点ではリゾルブしなくてはならないパラメータは存在しない。
３．各エンド・ポイントがグループ１に加入されるため、グループ・コールを期待して方法５００（図５）に従って共通のグループ・パラメータの再計算のリクエストがトリガされる。エンド・ポイント１が加入されると、唯一のグループ・メンバーとなるため、その全ての性能（Ａ，Ｂ，Ｃ）がグループについて共通となる。エンド・ポイント２が加入されると、性能Ｂ、Ｃだけがグループ・メンバーに共通となる。エンド・ポイント３が加入されると、性能Ｃだけがグループ・メンバーに共通となる。
４．エンド・ポイント１が新しい性能で再登録されると、性能Ｄだけがグループ・メンバーに共通となる。
５．エンド・ポイントは、グループ１にＳＩＰＩＮＶＩＴＥメッセージを送ることで呼を開始する。
６．グループ１は、グループ・マネージャに現在の共通の呼パラメータ（本例ではＤ）をリクエストする。
７．呼パラメータは、呼セットアップ・シグナリングの一部として様々なエンド・ポイントに配られる。

登録マネージャ２０２に注意を向けると、それは、変更ＳＩＰレジストリであり、ユーザ、端末エンド・ポイント、およびそれらの間のバインディングに関する情報を含む貯蔵所（repository）を表すことが好ましい。登録マネージャ２０２は、ディスパッチ装置および非ディスパッチ装置の両方を登録するよう構成されることが好ましい。登録マネージャ２０２は、システム上のエンド・ポイント（ユーザ／端末バインディング）を登録するためにＳＩＰＲＥＧＩＳＴＥＲリクエストの取り扱うことを含む、標準ＳＩＰレジストリ機能を実施するよう構成されることが好ましい。ＳＩＰリクエストがルーティングされるべき可能な宛先を決定するためにＳＩＰプロキシ２０４によってクエリーされてもよい。例えば、ＳＩＰプロキシ２０４がユーザ名を供給し、登録マネージャ２０２は該ユーザが登録されている端末アドレスのリストで応じることが好ましい。

上述の標準ＳＩＰレジストリ機能を実施することに加えて、登録マネージャ２０２は各端末エンド・ポイントのメディア性能および任意にはユーザ・プロフィールを記述する情報を維持するよう構成されることが好ましい。これらの端末性能は、例えば、標準ＲＥＧＩＳＴＥＲリクエストへの拡張として送られてもよく、画面の大きさ、入出力性能、有効なコーデックなどの属性を記述する。登録マネージャ２０２は、処理する成功した登録または再登録リクエストそれぞれをグループ・データベース・マネージャ２０８に通知するよう構成されることが好ましい。

グループ・データベース・マネージャ２０８に注意を向けると、それは、システム内に提供される様々なグループ・コンテキスト（即ち、グループ・ボイス、ビデオ、およびデータ）に関する情報を含む貯蔵所を表す。グループ・データベース・マネージャ２０８は、システム中の各グループに対するグループ・メンバーの加入を追跡し、好ましくは、一つ以上のグループに加入させるためにエンド・ポイントからのＡＦＦＩＬＩＡＴＥリクエストを処理し、それにより、グループの一人のメンバーが送信すると、全てのメンバーがメディアを受信するようになる。グループ・データベース・マネージャ２０８は、特定のグループに参加するための特定のユーザに対する承諾のシステム・プロビジョニング、ユーザの端末がグループと既に加入されている全ての他のエンド・ポイントの通信性能と互換性のある、即ち、リゾルブできる、通信性能を有するか否か、といった要素に基づいて加入を許可または拒絶する。グループ・データベース・マネージャ２０８は、優先順位、許可可能なセッション・パラメータ、セッション時間制限等の個々のグループに対するシステム・ポリシーのキーパでもあることが好ましい。

セッション・パラメータのレゾリューションが、グループにとって潜在的に複雑で時間がかかるため、セッション・パラメータは前もって計算されることが好ましい。従って、グループ・データベース・マネージャ２０８は、パラメータ・リゾルバによって計算される、各グループに対するリゾルブされた有効な組のセッション・パラメータを好ましくは記憶する。グループ・メンバーが加入されると、グループ・データベース・マネージャ２０８は、グループに対する記憶された一組（または数組）の有効なセッション・パラメータを更新する。更に多数の組のセッション・パラメータが使用シナリオの異なるカテゴリーに対して記憶されてもよい。例えば、特に高質ビデオのための組があってもよく、または、オーディオのための組があってもよい。

図６は、エンド・ポイントを特定のグループに加入させるためにグループ・データベース・マネージャ２０８によって実施されるステップを有する、本発明による方法６００を示す。方法６００は、本発明によると加入リクエストを含む、好ましくは、ＳＩＰであるアプリケーション層ルーティングによってリクエスト側（例えば、非ディスパッチ端末に成り代わったエンド・ポイントまたはグループ・エンティティ）からの第１のメッセージを受信するステップ６０２と、受信した加入リクエストの種類に応じて上述の加入リクエストに対する応答を生成するステップ６０４と、アプリケーション層ルーティングによって加入リクエストに対する応答をリクエスト側に通信するステップ６０６とを含む。

ＡＦＦＩＬＩＡＴＥリクエストは、ＳＩＰＵＡＣから送信され、１）本発明に従ってＡｓｓｏｃｉａｔｅ拡張ヘッダの使用を通じて加入することを望む一つ以上のユーザ・グループのリスト、２）所与のグループに加入すべき一つ以上のＣｏｎｔａｃｔヘッダのリスト、または、３）加入することが可能なグループのリストに対するクエリーを含んでもよい。ＡＦＩＩＬＩＡＴＥリクエストを受信すると、グループ・データベース・マネージャ２０８は、リクエストを確認し、解釈するよう、さらに、例えば、Ｓｕｃｅｓｓ、ＰａｒｔｉａｌＳｕｃｃｅｓｓ、ＤｅｎｙおよびＥｒｒｏｒなどの幾つかの可能なＳＩＰ応答の一つを生成するよう構成されることが好ましい。

具体的には、リクエストがＡｓｓｏｃｉａｔｅヘッダおよび少なくとも一つのＣｏｎｔａｃｔヘッダを介して少なくとも一つのグループを特定した場合、応答は、適用可能であれば、各グループのアナウンスメントが行われるマルチキャスト・アドレスと共に、リクエスト中の各Ｃｏｎｔａｃｔアドレスが現在加入しているグループを含む。リクエストがＡｓｓｏｃｉａｔｅヘッダを含まないが少なくとも一つのＣｏｎｔａｃｔヘッダを含む場合、応答は各特定されたＣｏｎｔａｃｔアドレスが加入しているグループのリストを含む。リクエストが少なくとも一つのＡｓｓｏｃｉａｔｅヘッダを含むがＣｏｎｔａｃｔヘッダを含まない場合、応答は、識別されたグループに現在加入している所与のユーザ（Ｔｏヘッダによって識別される）に対する全てのＣｏｎｔａｃｔアドレスのリストを含む。更に、リクエストがＡｓｓｏｃｉａｔｅおよびＣｏｎｔａｃｔヘッダ情報を含まない場合、応答は、識別されたエンド・ポイント（例えば、全てのＣｏｎｔａｃｔアドレス）のいずれかのユーザが加入（例えば、リクエストのＴｏヘッダによって識別される）している全てのグループのリストを含む。

ＳＩＰへの以下の好ましい拡張が上述の加入の機能性を可能にするために使用されてもよい。
ＡＦＦＩＬＩＡＴＥＲＥＱＵＥＳＴメッセージは、ユーザをグループと関連付けるためにＳＩＰＵＡＣによって生成される。ＡＦＦＩＬＩＡＴＥＲＥＱＵＥＳＴメッセージは、ユーザをグループ名に結び付けることを可能にする情報を含まなくてはならない。ＡＦＦＩＬＩＡＴＥＲＥＱＵＥＳＴメッセージの好ましいフォーマットを以下に示す。Ｒｅｑｕｅｓｔメッセージに対する一般的なＳＩＰヘッダ・フォーマットに従い（即ち、ヘッダＶｉａ、Ｆｒｏｍ、Ｔｏ、Ｃａｌｌ−ＩＤ、Ｃｓｅｑ、Ｅｘｐｉｒｅｓを含む）、更に、本発明によるとＡＦＦＩＬＩＡＴＥヘッダおよびＡｓｓｏｃｉａｔｅヘッダを含む。

以下の例では、ＡＦＦＩＬＩＡＴＥリクエストは、ユーザが多数のグループに加入している仮定のシステムにおいてみられるものである。本例では、記録されているアドレス（ＡｏＲ：Address of Record ）は、ユーザ「ｍ．ｋｏｒｕｓ」が自身のコンタクト・エンド・ポイント・アドレス「korus@ht2137.mot.com」をグループ「ｃａｓｐｅｒ＿ｔｅａｍ」および「ｔｅｃｈ＿ｔｅａｍ」に加入させようとしていることを示す。加入が成功すると、ユーザは、加入されたコンタクト・エンド・ポイントにおいてこれらのグループに対するセッションに参加することができる。リクエストは、以下のフォーマットであることが好ましい。

ユーザは、両方ではなくＡｓｓｏｃｉａｔｅまたはＣｏｎｔａｃｔヘッダの所望の組み合わせでＡＦＦＩＬＩＡＴＩＯＮリクエストを送ることで加入サーバ（即ち、グループ・データベース・マネージャ２０８）をクエリーすることもできる。例えば、所与のグループに加入している所与のユーザに対する全てのＣｏｎｔａｃｔアドレスのリストを得るためである。リクエストは、以下のフォーマットであることが好ましい。

更に、以下の好ましいフォーマットを有するリクエストにより、特定のユーザに対する全ての加入しているグループのリストを含む応答が生成される。

ＳＩＰＲＥＧＩＳＴＥＲメッセージに対するＳＩＰＲＥＳＰＯＮＳＥと同様に、ＳＩＰＲＥＳＰＯＮＳＥメッセージがＡＦＦＩＬＩＡＴＥＲＥＱＵＥＴトランザクションを完了するために必要である。ＡＦＦＩＬＩＡＴＥ応答のコンテンツは、ユーザが加入することをリクエストする各グループに対するＡｃｃｅｐｔ／Ｄｅｎｙ、および各グループに対する割り当てられたマルチキャスト・アドレス（制御用）またはユニキャストまたはマルチキャスト・アドレス（メディア用）のリストを含んでもよい。ＡＦＦＩＬＩＡＴＥ応答の好ましいフォーマットは

である。

加入が拒絶された全てのグループに対して、有効期限がゼロに設定されることが好ましく、幾つかのリクエストされた加入が拒絶されたことをリクエスト側に示すために代わりの応答ステータスが使用されてもよい。ＳＩＰのＲＥＧＩＳＴＥＲリクエストおよびその応答のように、ＡＦＦＩＬＩＡＴＥリクエスト応答メッセージは、受信したリクエストのＶｉａヘッダのリストによって特定される経路に従ってリクエスト側に戻されることが好ましい。Ｃｏｎｔａｃｔヘッダは、ＳＩＰのＲＥＧＩＳＴＥＲリクエスト・セマンティックと最大の一貫性を得るようリクエスト内の加入バインディングを特定するためだけに使用されることが好ましい。

フロア・コントローラ２３０に注意を向けると、それは、関連するメディア・ストリームまたは複数のストリームへのアクセスを管理する責任を担う。フロア・コントローラ２３０は、エンド・ポイントからフロアへのリクエストを処理し、どのエンド・ポイントがメディア・チャネル上でメディアを調達することが可能かを判断するために仲裁する。フロア・コントローラ２３０は、各メディア・ストリームに対して別々の仲裁を行い、仲裁はシステムにおける規則またはポリシーに基づく。フロア・コントローラ２３０が特定のエンド・ポイントに対してフロアを与えると、その変更を帯域幅マネージャ２３２に好ましくは通知することで、必要であれば、帯域幅確保が新しいエンド・ポイントにシフトされる。セッションがメディアに対するハングタイムによって制御される場合、フロア・コントローラ２３０はハングタイムがいつ期限切れとなるかをセッション・コントローラ２０６に好ましくは通知する。

ＳＩＰプロキシ２０４に注意を向けると、それは、登録マネージャ２０２によって維持される関連性に応じて目標とする論理エンティティに制御および情報メッセージを方向付ける標準ＳＩＰプロキシである。

グループ・エンティティ・マネージャ２１２に注意を向けると、それは、各グループ・エンティティ２１０を作成、維持、および無効化する責任を担うことが好ましい。適切なグループ・エンティティ２１０にＳＩＰリクエストをルーティングする専用のＳＩＰプロキシとして構成されることが好ましい。グループ・コンテキストにおける新しいセッションの確立に対する全てのリクエストは、グループ・エンティティ・マネージャ２１２を通じてルーティングされる。グループ・エンティティ・マネージャ２１２は、グループ・エンティティが存在しない場合にセッションがセットアップされたとき、あるグループに対してグループ・エンティティ２１０のインスタンスを作成する。該グループへの将来的なセッション・セットアップ・シグナリングは、好ましくは、グループ・エンティティ・マネージャ２１２によってグループ・エンティティ２１０にルーティングされる。

個別プロキシ・マネージャ２１８に注意を向けると、それは、各個別プロキシ２１６を作成、維持、および無効化する責任を担うことが好ましい。適切な個別プロキシ２１６に対してＳＩＰリクエストをルーティングする専用のＳＩＰプロキシとして構成されることが好ましい。個別、例えば、ポイント・ツー・ポイント・コンテキストにおける新しいセッションの確立に対する全てのリクエストは個別プロキシ・マネージャ２１８を通じてルーティングされる。個別プロキシ・マネージャ２１８は、セッションがセットアップされるとエンド・ポイントに対して個別プロキシ２１６のインスタンスを作成する。

マルチキャスト・アドレス・マネージャ２２０に注意を向けると、それは、マルチキャスト・アドレスのプールを管理し、半永久的および一時的のいずれの割り当ても行う。マルチキャスト・アドレス・マネージャ２２０は、どのようにして、いつ、どれだけ使用されるかを決定するために割り当てられたアドレスの使用のタイプおよび長さをモニタリングする性能を有することが好ましい。これにより、マネージャ２２０は、幾らかの時間使用されていないアドレスを再請求し、プールが空になった場合に使用中のアドレスの再請求を優先させることができる。

従って、マルチキャスト・アドレス・マネージャは、１）外部処理によって要求されたとき一時的または半永久的にプールからマルチキャスト・アドレスを供給し、２）外部処理によって戻されたときプールにアドレスを元に戻し、３）アドレスがいつどのような目的で使用されるかに関する統計をとり、４）プールを満たしてルータ状態を最小化したままにするために割り当てられたがある閾値時間を超えて未使用である半永久アドレスを再請求し、５）プールが空になった場合に、使用されてなく時間切れでないアドレスを再請求し、６）プールが空になった場合に、ストリームの優先順位、ストリームのタイプ、ストリームの使用履歴などに基づいて活性的に使用されているアドレスを再請求し、７）多数のマルチキャスト・アドレスを利用するメディアおよび制御ストリームを単一のアドレスに集約する機能を実施するよう構成される。機能４乃至７は、随意的に、システムからの認可を必要とする場合もある。

図７は、利用可能なマルチキャスト・アドレスのプールを管理するためのマルチキャスト・アドレス・マネージャ２２０の本発明による方法７００を示す。方法７００は、利用可能なマルチキャスト・アドレスのプールを生成するステップ７０２と、マルチキャスト・アドレスに対するリクエストを受信するステップ７０４と、少なくとも第１の制限を受けるマルチキャスト・アドレスを使用のために割り当てるステップ７０６と、上述の割り当てられたマルチキャスト・アドレスの使用をモニタリングするステップ７０８と、上述のモニタリングに応じて第１の条件が満たされたことが検出されると上述の割り当てられたマルチキャスト・アドレスを再請求し、上述の割り当てられたマルチキャスト・アドレスを利用可能なマルチキャスト・アドレスのプールの元の位置に戻すステップ７１０と、を備える。

マルチキャスト・アドレス・マネージャ２２０が方法７００を実施する、本発明による特定のシステムの実行を示すバウンス・チャートを以下に示す。この実行は、ＳＩＰエンド・ポイント、グループ（データベース）マネージャ（２０８）、グループ（エンティティ）ゲートウェイ（２１０）、セッション・コントローラ（２０６）、および（マルチキャスト）アドレス・マネージャ（２２０）を含むアーキテクチャ２００（図２）におけるエンティティによって実施される以下に挙げる六つの機能的ステップを含む。

この実行のステップ１乃至６は次の通りである。
１．グループ作成時に、グループ・マネージャが半永久的な割り当てのためにマルチキャスト・アドレスをリクエストする。アドレス・マネージャは、「マルチキャスト・アドレス１」を戻す。
２．エンド・ポイントがグループに加入される。応答によりエンド・ポイントが参加する「マルチキャスト・アドレス１」をエンド・ポイントに知らせる。
３．エンド・ポイントは、グループ・ゲートウェイにＩＮＶＩＴＥを送出することで二つのメディア・ストリーム（例えば、音声およびビデオ）に対するセッションを開始する。グループ・ゲートウェイは、セッションの許可をセッション・コントローラに伺いリソースをリクエストする。セッション・コントローラは、メディア・ストリームのうち一つだけがマルチキャスト・アドレスを割り当てられていることを認識し、アドレス・マネージャに更なるアドレスをリクエストし、「マルチキャスト・アドレス２」が割り当てられる。次に、セッション・コントローラは、「マルチキャスト・アドレス１」および「マルチキャスト・アドレス２」が使用中であることをアドレス・マネージャに知らせる。
４．「マルチキャスト・アドレス２」がグループ・ゲートウェイに戻され、「マルチキャスト・アドレス１」および「マルチキャスト・アドレス２」がセッションに使用されるべきであることを示す応答を作成して発信元に戻す。エンド・ポイントは、既に参加している「マルチキャスト・アドレス１」で第１のメディア（例えば、音声）を調達し始める。同時に、エンド・ポイントは、「マルチキャスト・アドレス２」に参加し、第２のメディア（例えば、ビデオ）を調達し始める。
５．セッションの終わりには、エンド・ポイントがＢＹＥメッセージを送出する。これにより、セッション・コントローラは、「マルチキャスト・アドレス２」をプールに解放し（一時的な割り当てであったため）、「マルチキャスト・アドレス１」が再びアイドル状態であることをアドレス・マネージャに知らせる。
６．「マルチキャスト・アドレス１」が幾らかの期間にわたって使用されていない場合、タイマが時間切れとなり、アドレス・マネージャが割り当てを再請求し、ツリーの一部であるどのエンド・ポイントも強制的に離される。

本実行では、セッション・コントローラは、短期アドレスをリクエストし解放するための制御点として知られているが、他のエンティティがこの機能を実施してもよい。
本発明によると、ＳＩＰセッション招待の受取側によってメディア・チャネルが割り当てられるよう標準ＳＤＰセマンティックに対する拡張が提供される。本発明の以下の実施形態は、これらの拡張を用いてエンド・ポイント間のセッションにおけるメディア交換のために少なくとも一つのアドレス（例えば、マルチキャスト・アドレス）を割り当てる方法を実行する。

通常、ＳＤＰパケットは、セッション、メディア・タイプ、チャネル・ポート番号、チャネルＩＰアドレス、およびメディア・エンコーディングを識別する。例えば、以下のＳＤＰパケットは、Ｈ３３２フロア制御を用いて関連するメディア制御チャネルでマルチキャスト・オーディオ・セッションを識別する。

ＳＤＰパケットの「ｍ＝」フィールドは、セッション内で使用されるべきメディア・タイプおよびメディアが受信されるポートを識別する。ＳＤＰパケットの「ｃ＝」フィールドは、特定のメディア・タイプに対する使用されるべきチャネル（ＩＰアドレス）を識別する。チャネル識別子は、ＳＤＰパケット内の全てのメディア・ストリームまたは個々のメディア・タイプに適用可能である。後者の場合、メディア・タイプ識別子は、対応するチャネル識別子によって後続される。

しかしながら、上述のパケット構造は、全てのパーティ間でマルチキャスト・メディアをセッションに対して調達するためにエンド・ポイントが多数のパーティとの間で新しいセッションをリクエストする場合には使用できない。この場合、システムのインフラストラクチャにおける何らかのプロセスで中央化されるような何らかの形態のマルチキャスト・チャネル割り当ての調整が必要となる。この欠点に取り組むためには標準ＳＤＰパケットは、マルチキャスト・チャネルのこのような調整のために、本発明に従って以下に説明するように再構成されることが好ましい。

セッション開始リクエストのＳＤＰパケットは、セッションによって実施されるメディアのタイプをまだ識別できることが好ましい。通常、空アドレス（例えば、ｃ＝ＩＮＩＰ４０．０．０．０）を特定するチャネル識別子は、対応するメディア・ストリームが待たされなくてはならないことを示す。ヌル・ポート識別子を特定する対応するメディア・タイプとチャネル識別子セマンティックを組み合わせることにより、適当なアドレスが割り当てられる必要があることを調整エンティティにシグナリングする手段をセッションの開始側に提供する。セッションの開始側は、作成されるべきセッションを説明するために以下のＳＤＰパケットを好ましくは作成する。

セッション属性（ａ＝ｔｙｐｅ：Ｈ３３２）は、リクエストされるセッションがＨ．３３２フロア制御を必要とすることを受取側にシグナリングする。メディア識別子およびチャネル識別子は、それぞれヌル・ポートおよびアドレスの割り当てを有する。これにより、対応するマルチキャスト・メディア・チャネルおよびポートと、ユニキャスト（またはマルチキャスト）制御チャネルおよびポートが割り当てられるべきことを受取側にシグナリングする。受取側は、本セッションに割り当てるべきアドレスおよびポート割り当てを決定するために対応するシステム・レベル・プロセスと調整し、割り当てられたアドレスおよびポートを含む変更ＳＤＰパケットを戻す。開始側は、変更ＳＤＰパケットを新しく割り当てられたメディア・チャネルで受け入れる。

代わりに、ＲＦＣ２３２７で定義される拡張機構を用いて、新しいセッション・レベル属性が定義され、マルチパーティ・セッションにどのようにしてアドレスが割り当てられるか、更に、所与のメディア・ストリーム上で使用されるメッセージングのタイプ（例えば、ユニキャスト対マルチキャスト）のより明白な制御が提供される。以下に、ＳＤＰパケットがメディア・アドレス割り当てに対する拡張属性で増強された、本発明による一つの実施形態を示す。

本例では、セッション・レベル属性（ｘ＿multiparty）は、全ての割り当てられていないメディア・ストリームに対してマルチキャスト・アドレスを割り当てることをメディア制御エンティティに知らせるために使用される。しかしながら、セッション・レベル属性（ｘ＿peer２peer）は、フロア制御エンティティにユニキャスト・アドレスが割り当てられるべきことをメディア・コントローラに特定する。様々なセッションおよびストリーム・レベル属性を用いることにより、システムによってマルチキャストおよびユニキャスト・ストリームのどの組み合わせも割り当てられることが可能となる。

最後に、ポリシー・マネージャ２２４に注意を向ける。消費者による将来的なマルチメディア・システムの様々な使用方法の性質により、システムには多くのフレキシビリティが組み込まれていなくてはならない。システム挙動を制御する明確で管理しやすいポリシーの組を作成することで、消費者は、特別なソフトウェア構築を必要とすることなくシステムを合わせることができる。ポリシー・マネージャは、様々なポリシーが記憶されているポリシー・データベースへのアクセスを制御するよう好ましくは構成される。

上述の通り、アーキテクチャ２００（図２）におけるエンド・ポイントは、ディスパッチ・エンド・ポイントであることが好ましい。しかしながら、少なくとも一つのエンド・ポイントが非ディスパッチ端末を備える場合、本発明の一つの実施形態は、非ディスパッチ端末とのセッションを容易にする方法を提供する。図８は、非ディスパッチ端末との通信を容易にする方法８００を示すフロー図である。ステップ８０２では、非ディスパッチ端末を備える第１のエンド・ポイントと少なくとも一つの他のエンド・ポイントとの間のセッションのリクエストを含む情報を有する第１のメッセージを受信する。ステップ８０４では、非ディスパッチ端末が少なくとも一つの機能を実施することができないことに応じて非ディスパッチ端末を備える第１のエンド・ポイントを検出する。最後に、ステップ８０６では、非ディスパッチ・エンド・ポイントとのセッションを容易化するために少なくとも一つのサービス・エンティティによって第１のエンド・ポイントに成り代わって、その少なくとも一つの機能を実施する。

好ましくは、グループ・エンティティ２１０は、第１のメッセージを受信し、非ディスパッチ装置がグループ・コールを実施しようとしていることを検出する。例えば、非ディスパッチ端末がグループ・エンティティ２１０にＩＮＶＩＴＥを送出すると、グループ・エンティティは、ＩＮＶＩＴＥＳＤＰにおけるフロア制御プロフィールの欠如、専用のディスパッチ・ヘッダの欠如、登録および／または加入記録の欠如、または、ＯＰＴＩＯＮＳコマンドによってクエリーされる性能によって示されるいずれか一つの手段によって可能なディスパッチでないことを検出し得る。

これらの手段を用いて、グループ・エンティティは、エンド・ポイントがグループと加入する性能がないことを検出する。この場合、グループ・エンティティはエンド・ポイントを自動的に加入させる。グループ・エンティティは、標準装置のメディアをメディア・マネージャに方向付ける標準装置を特に目標としたシグナリングを好ましくは生成する。このシグナリングは、ディスパッチ可能エンド・ポイントに分配されたものとは異なるセッション・パラメータを有する。

グループ・エンティティは、端末がフロア・コントローラ２３０と通信することができないと検出することもある。この場合、全二重装置、例えば、非ディスパッチ・エンド・ポイントに対して話者が仲裁されたフロア制御を課すよう好ましくは構成されるメディア・マネージャに対してエンド・ポイントがメディアを方向付けるよう、グループ・エンティティは非ディスパッチ・エンド・ポイントへのシグナリングを好ましくは生成する。メディア・マネージャは、音声が非ディスパッチ・エンド・ポイントによって調達されるときフロア・コントローラにフロア・リクエストを好ましくは生成する。オプションとして、トーンまたは他のオーディオ情報は、他の誰かがこれ以上話させないようにするフロアを有するときに話そうとするユーザに送出される。話者を遮ることはＳＩＰシグナリングによってサポートされないため、明白なシグナリングの代わりにオーディオ情報がこの目的のために使用される。

グループ・エンティティは、端末がＩＰマルチキャストを介してメディアを交換することができないことを検出する。この場合、グループ・エンティティは、非ディスパッチ・エンド・ポイントへのシグナリングを好ましくは生成し、ユニキャストおよびマルチキャスト・メディア・ストリームをブリッジするよう好ましくは構成されるメディア・マネージャに対してエンド・ポイントがメディアを方向付けるようにする。例えば、非ディスパッチ装置がフロアを有するとき、そのユニキャスト・メディアはディスパッチ端末によって使用される共通のマルチキャスト・チャネル上でメディア・マネージャによって再送信される。ディスパッチ端末がフロアを有するとき、そのマルチキャスト・メディアは複製され、ユニキャストを用いて非ディスパッチ装置に送出される。更に、非ディスパッチ装置がマルチキャスト可能である場合、装置は、別のユニキャスト・ストリームを生成する代わりに正常なマルチキャスト・トラフィックを聞くよう方向付けられる。しかしながら、着信経路では、標準装置は、送信がフロア・コントローラによって訓練されないため、マルチキャスト・チャネル上で送信しないことが好ましい。

方法８００による非ディスパッチ端末との通信を可能にする本発明による特定のシステム実行を例示するバウンス・チャートを以下に示す。この実行は、標準（即ち、非ディスパッチ）端末、グループに加入された二つのディスパッチ端末、グループ（エンティティ）ゲートウェイ（２１０）、グループ（データベース）マネージャ（２０８）、ポリシー・マネージャ（２２４）、メディア・マネージャ（２２６）、およびフロア・コントローラ（２３０）を含むアーキテクチャ２００（図２）におけるエンティティによって実施される以下に挙げる九つの機能的ステップを含む。

１．標準ＳＩＰ装置がグループにＳＩＰアドレスをアドレス指定することでグループ・コールを開始する。
２．任意には、グループ・ゲートウェイが標準ＳＩＰ手順を用いてその性能について装置にクエリーする。
３．任意には、グループ・ゲートウェイがその判断をシステムのポリシーに部分的に基づかせるグループ・マネージャと開始側を許可する。更に、グループ・マネージャは、このエンド・ポイントをグループに自動的に加入させて全ての将来的なグループ・コールの一部になるよう選択してもよい。この加入が実施されると、ユーザが提供されるグループ・メンバーよりもより多くの制限が与えられる。
４．ＳＩＰシグナリングは、メディア・マネージャ（着信メディアのため）のアドレス並びにセッション・パラメータ（コーデック、ビットレートなど）と共に開始側に戻される。グループ・ディスパッチ・セッション・パラメータは、ブロードキャスト・アナウンスメントを用いて正常なグループ・メンバーに送出される。更に、メディア・マネージャは、このユーザからの全てのトーク・スパートの始まりをフロア制御へのリクエストに変換し、ユニキャストとマルチキャスト・メディアとの間で変換するようプログラミングされる。
５．開始側は、話し始め、音声パケットをメディア・マネージャに送出する。メディア・マネージャは、音声の存在を検知してフロアへのリクエストを生成する。メディアは、正常なグループ・メンバーにマルチキャストされる。開始側が話し終えると、沈黙によりフロアが解放される。
６．正常なグループ・メンバーが明確なフロア制御シグナリングを用いてフロアを要求する。
７．フロアが与えられると、ユーザはマルチキャストを介して音声を送信し始める。マルチキャストされたメディアがユニキャストを介して標準エンド・ポイントに送出される。
８．標準エンド・ポイントが、現在の話者の上を話そうとすると、そのトーク・スパートはフロアへのリクエストを再び生成し、拒絶される。この拒絶はエンド・ポイントにトーンの短いバーストまたは他のオーディオ・データを送出して話せなくするようにすることで示される。
９．現在のフロア保持者がＰＴＴを解放し、フロアを手放す。

アーキテクチャ２００によって例示される本発明による通信セッションがどのようにして好ましくはセットアップされるかのサマリーを示す。エンド・ポイント２４０は、アプリケーション層ルータ２０４にＳＩＰＩＮＶＩＴＥを送出し、ＩＮＶＩＴＥのＴｏヘッダにおいて宛先アドレスで特定されるサブドメインに基づいてグループ・エンティティ・マネージャ２１２または個別プロキシ・マネージャ２１８のいずれかに転送される。グループ・エンティティ・マネージャ２１２がＩＮＶＩＴＥを受信した場合、一つも存在しないとグループに対する新しいグループ・エンティティ２１０をインスタンス作成する。そのグループに対する将来的なセッション・セットアップ・シグナリングは、グループ・エンティティ２１０にルーティングされる。個別プロキシ・マネージャ２１８がＩＮＶＩＴＥを受信した場合、新しい個別セッションに対する新しい個別プロキシ２１６をインスタンス作成する。

個別プロキシ２１６またはグループ・エンティティ２１０は、セッションがセットアップされるかを決定するためにセッション・コントローラ２０６と通信する。セッションの受け入れの際、セッション・コントローラは、セッションを進めるために必要な情報をグループ・エンティティまたは個人に通知する。グループ・エンティティが情報を受信した場合、グループ・エンティティは、セッションに関わるエンド・ポイントにセッション・シグナリングを生成する。セッション・シグナリングは、確認グループ・セッション（または個別セッション）に対してＳＩＰＩＮＶＩＴＥメッセージ、または、未確認グループ・セッションに対してＳＡＰアナウンスメントの形態をとる。ＩＮＶＩＴＥのＦｒｏｍヘッダで示されるソースは、グループ・セッション（個別セッションに対するセッション開始側）に対するグループ名である。グループ・メンバーは、該グループに対してセットアップされるマルチキャスト・チャネル上でＳＡＰアナウンスメントを受信し、グループ・メンバーは、グループ加入中にマルチキャスト・チャネルを知り、参加する。

一旦セッションが実施されると、エンド・ポイントは、フロア・コントローラ２３０にフロア制御シグナリングを送出してフロアをリクエストする。フロア・コントローラ２３０は、そのセッションに対する規則およびポリシーを用い、フロアを与えるかを決定するためにストリームする。最後に、セッションは、本願と同時に出願された“グループ通信のための方法およびシステム（METHOD AND SYSTEM FOR GROUP COMMUNICATIONS）”と題された米国特許出願番号第１０／１０／３３４，５２１号に記載される方法に従って変更され終了される。

本発明は、特定の実施形態と共に説明されたが、更なる利点および変更が当業者には容易となるであろう。従って本発明は、その広い面において、図示し説明した特定の詳細、代表的な装置、および例示的な例に制限されない。様々な変化、変更、および変形例が前述の説明を鑑みて当業者には明らかとなるであろう。従って、本発明は、前述の説明によって制限されず、添付の特許請求の範囲の技術思想および範囲に従って全ての変化、変更、および変形例を包含する。

従来技術の呼モデル・アーキテクチャの簡単なブロック図。本発明による呼モデル・アーキテクチャのブロック図。図２に示す本発明による呼モデル・アーキテクチャの階層図。図２に示す本発明による呼モデル・アーキテクチャの階層図。グループに対して一組の共通の通信性能を生成する、本発明による方法を示す図。エンド・ポイントをグループに加入させる、本発明による方法を示す図。マルチキャスト・アドレスのプールを管理する、本発明による方法を示す図。非ディスパッチ端末を備えるエンド・ポイントとの通信を可能にする、本発明による方法を示す図。

Claims

論理エンティティおよびその物理対応物をそれぞれ備える複数のエンド・ポイントを有する通信システムにおいて、少なくとも二つの前記エンド・ポイント間のセッションを制御および管理するシステムであって、
前記通信システムにおける前記論理エンティティのそれぞれとその物理対応物との間の関連性を維持して、前記論理エンティティのそれぞれへのアプリケーション層ルーティングを可能にする登録マネージャと、
前記登録マネージャによって維持される関連性に応じて目標とする論理エンティティに制御および情報メッセージを方向付けるアプリケーション層ルータと、
通信システム・リソースおよび前記少なくとも二つのエンド・ポイントのリソースに応じて少なくとも二つのエンド・ポイントの間のリクエストされたセッションの状態を判断し、前記リクエストされたセッションを許可する際に対応するセッション・パラメータの組を決定するセッション・コントローラと、
前記アプリケーション層ルータに通信可能に接続され、少なくとも一つのグループを含むグループ・リストを保持し、該グループ・リストに含まれる各グループに対して、該グループと少なくとも一つの加入したエンド・ポイントとの間の関連性を維持するグループ・データベース・マネージャと、
前記グループ・データベース・マネージャに通信可能に接続され、前記グループ・データベース・マネージャによって保持されるグループ・リスト中の各グループに関連付けられる少なくとも一つのグループ・エンティティであって、該グループ・エンティティのそれぞれは前記登録マネージャおよび前記セッション・コントローラに通信可能に接続され、前記アプリケーション層ルータから方向付けられるメッセージを受信するために前記アプリケーション層において命名されてアドレス指定可能にされ、該グループ・エンティティのそれぞれは、更に、前記アプリケーション層ルーティングによって、開始側エンド・ポイントとグループ・エンティティの関連するグループとの間でのグループ指向セッションをリクエストする第１のメッセージを受信し、前記リクエストされたグループ指向セッションを前記セッション・コントローラに通信し、前記アプリケーション層ルーティングによって、前記リクエストされたグループ指向セッションの状態および許可されたグループ指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントに通信し、前記許可されたグループ指向セッションおよび前記対応するセッション・パラメータの組を前記関連付けられたグループに加入している他のエンド・ポイントのそれぞれに通信するように構成される、少なくとも一つのグループ・エンティティと、
を備える、エンド・ポイント間のセッションを制御および管理するシステム。
請求項１に記載のシステムであって、更に、前記セッション・コントローラおよび前記グループ・データベース・マネージャに通信可能に接続され、少なくとも二つのエンド・ポイント間のセッションにおいて使用可能であり、かつ前記少なくとも二つのエンド・ポイント間の許可されたセッションの対応するセッション・パラメータの組を決定するために前記セッション・コントローラによって使用可能な少なくとも一組の潜在的なセッション・パラメータを確立するパラメータ・リゾルバを備える、エンド・ポイント間のセッションを制御および管理するシステム。
請求項１に記載のシステムであって、更に、前記登録マネージャおよび前記セッション・コントローラに通信可能に接続され、開始側エンド・ポイントと少なくとも一つの目標とするエンド・ポイントとの間での個別指向セッションをリクエストする前記アプリケーション層ルータから方向付けられた第１のメッセージを遮断し、前記リクエストされた個別指向セッションを前記セッション・コントローラに通信し、前記アプリケーション層ルーティングによって、前記リクエストされた個別指向セッションの状態および許可された個別指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントに通信し、前記許可された個別指向セッションおよび対応するセッション・パラメータの組を前記少なくとも一つの目標とするエンド・ポイントに通信する少なくとも一つの個別プロキシを備える、エンド・ポイント間のセッションを制御および管理するシステム。
請求項１に記載のシステムであって、更に、前記通信システムに通信可能に接続され、マルチキャスト・アドレスのプールを管理し、専用のマルチキャスト・アドレスに対するリクエストに応答して前記専用のマルチキャスト・アドレスを割り当てるマルチキャスト・アドレス・マネージャを備え、該マルチキャスト・アドレス・マネージャは、前記セッション・コントローラに通信可能に接続され、専用のマルチキャスト・アドレスに対する前記セッション・コントローラからのリクエストに応答して前記専用のマルチキャスト・アドレスを割り当て、該マルチキャスト・アドレス・マネージャは、前記グループ・データベース・マネージャに通信可能に接続され、専用のマルチキャスト・アドレスに対する前記グループ・データベース・マネージャからのリクエストに応答して前記専用のマルチキャスト・アドレスを割り当てる、エンド・ポイント間のセッションを制御および管理するシステム。
請求項１に記載のシステムにおいて、前記対応するセッション・パラメータは、前記グループに加入している少なくとも一つのエンド・ポイントをサービス指定エンティティに方向付ける情報を含む、システム。
論理エンティティおよびその物理対応物をそれぞれ備え、かつセッション開始プロトコル（ＳＩＰ）プロトコル・ユーザ・エージェント・クライアント（ＵＡＣ）、およびＳＩＰユーザ・エージェント・サーバ（ＵＡＳ）をそれぞれ含む複数のエンド・ポイントを有する通信システムにおいて、少なくとも二つの前記エンド・ポイント間のセッションを制御および管理するシステムであって、
前記通信システムにおける前記論理エンティティのそれぞれとその物理対応物との間の関連性を維持して、前記ＳＩＰプロトコルを介して前記論理エンティティのそれぞれへのアプリケーション層ルーティングを可能にする登録マネージャと、
前記登録マネージャによって維持される関連性に応じて目標とする論理エンティティに制御および情報メッセージを方向付けるＳＩＰプロキシと、
通信システム・リソースおよび前記少なくとも二つのエンド・ポイントのリソースに応じて少なくとも二つのエンド・ポイントの間のリクエストされたセッションの状態を判断し、前記リクエストされたセッションを許可する際に対応するセッション・パラメータの組を決定するセッション・コントローラと、
前記ＳＩＰプロキシに通信可能に接続され、少なくとも一つのグループを含むグループ・リストを保持し、該グループ・リストに含まれる各グループに対して、該グループと少なくとも一つの加入したエンド・ポイントとの間の関連性を維持するグループ・データベース・マネージャと、
前記グループ・データベース・マネージャに通信可能に接続され、前記グループ・データベース・マネージャによって保持されるグループ・リスト中の各グループに関連付けられる少なくとも一つのグループ・エンティティであって、該グループ・エンティティのそれぞれは前記登録マネージャおよび前記セッション・コントローラに通信可能に接続され、前記ＳＩＰプロキシから方向付けられるメッセージを受信するためにＳＩＰＵＡＳを含み、更に、開始側エンド・ポイントとグループ・エンティティの関連するグループとの間でのグループ指向セッションをリクエストする第１のメッセージを前記開始側エンド・ポイントのＳＩＰＵＡＣから受信し、前記リクエストされたグループ指向セッションを前記セッション・コントローラに通信し、前記リクエストされたグループ指向セッションの状態および許可されたグループ指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントのＳＩＰＵＡＣに通信し、前記許可されたグループ指向セッションおよび前記対応するセッション・パラメータの組を前記関連付けられたグループに加入している他のエンド・ポイントのそれぞれに通信するように構成される、少なくとも一つのグループ・エンティティと、
を備える、エンド・ポイント間のセッションを制御および管理するシステム。
請求項６に記載のシステムであって、更に、前記セッション・コントローラに通信可能に接続され、少なくとも二つのエンド・ポイント間のセッションにおいて使用可能であり、かつ前記少なくとも二つのエンド・ポイント間の許可されたセッションに対して対応するセッション・パラメータの組を決定するために前記セッション・コントローラによって使用可能な少なくとも一組の潜在的なセッション・パラメータを確立するパラメータ・リゾルバを備える、エンド・ポイント間のセッションを制御および管理するシステム。
請求項６に記載のシステムであって、更に、前記登録マネージャおよび前記セッション・コントローラに通信可能に接続された少なくとも一つの個別プロキシを備え、該個別プロキシのそれぞれは、前記ＳＩＰプロキシから方向付けられたメッセージを遮断するＳＩＰＵＡＳを含み、更に、開始側エンド・ポイントと少なくとも一つの目標とするエンド・ポイントとの間での個別指向セッションをリクエストする第１のメッセージを前記開始側エンド・ポイントのＵＡＣから受信し、前記リクエストされた個別指向セッションを前記セッション・コントローラに通信し、前記リクエストされた個別指向セッションの状態および許可された個別指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントのＵＡＣに通信し、前記許可された個別指向セッションおよび対応するセッション・パラメータの組を前記少なくとも一つの目標とするエンド・ポイントの前記ＵＡＳに通信するように構成される、エンド・ポイント間のセッションを制御および管理するシステム。
少なくとも一つのサービス・エンティティと論理エンティティおよび端末をそれぞれに備える複数のエンド・ポイントとを有する通信システムにおいて、少なくとも二つの前記エンド・ポイント間のセッションを容易化する方法であって、
非ディスパッチ端末を備える第１のエンド・ポイントと少なくとも一つの他のエンド・ポイントとの間のセッションに対するリクエストを含む情報を有する第１のメッセージを受信するステップと、
前記第１のエンド・ポイントが前記セッションの間にメディアを調達するためにフロア制御リクエストを生成することができないことに応じて、前記第１のエンド・ポイントが非ディスパッチ端末を備えることを検出するステップと、
前記第１のエンド・ポイントと前記少なくとも一つの他のエンド・ポイントとの間での前記セッションを容易化するために、前記少なくとも一つのサービス・エンティティに前記第１のエンド・ポイントに成り代わって前記フロア制御リクエストを実行させるステップと、
前記第１のエンド・ポイントに成り代わって第１のサービス・エンティティに前記フロア制御リクエストを生成させるために、前記第１のエンド・ポイントにそのメディアを前記通信システムに含まれる前記第１のサービス・エンティティに方向付けさせるよう前記第１のエンド・ポイントへのシグナリングを生成するステップと、
別のエンド・ポイントがフロアを有するためにメディアを調達できないことを前記第１のエンド・ポイントに通知するよう前記第１のエンド・ポイントに情報を送るステップと、を備え、
前記通信システムはメディア・マネージャ・サービス・エンティティおよびフロア制御サービス・エンティティを含み、前記メディア・マネージャ・サービス・エンティティは前記第１のエンド・ポイントに成り代わって前記フロア制御サービス・エンティティにフロア制御リクエストを生成する、二つのエンド・ポイントの間のセッションを容易化する方法。
請求項９に記載の方法において、
前記第１のメッセージは、前記第１のエンド・ポイントと前記少なくとも一つの他のエンド・ポイントが加入しているグループとの間のセッションに対するリクエストを含み、
前記第１のエンド・ポイントは、前記グループに加入することができず、
前記グループ加入は、前記第１のエンド・ポイントと前記少なくとも一つの他のエンド・ポイントとの間の前記セッションを容易化するために前記第１のエンド・ポイントに成り代わって実行される、二つのエンド・ポイントの間のセッションを容易化する方法。