JP5363461B2

JP5363461B2 - グループ呼機能の問い合わせ

Info

Publication number: JP5363461B2
Application number: JP2010507361A
Authority: JP
Inventors: マッツオラスティッレ，; ヤンホルム，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-05-11
Filing date: 2008-04-21
Publication date: 2013-12-11
Anticipated expiration: 2028-04-21
Also published as: CN101682617B; KR101402433B1; JP2010527200A; US8295207B2; CA2686876C; WO2008140391A1; CN101682617A; US20080279119A1; KR20100016394A; HK1142188A1; CA2686876A1; EP2147540A1; EP2147540A4; MX2009011715A

Description

本発明は、電話通信ネットワークにおけるマルチメディア電話会議呼を扱うためのシステム及び方法に関するものである。

電話通信ネットワークにおけるマルチメディア電話会議は、多くの標準化団体において標準化されることが目的とされている。ネットワークＩＴＵ−Ｔに基づくパケットに関しては、包括的な提案Ｈ．３２３下でマルチメディア通信における多くの提案が策定されている。Ｈ．３２３は、メディア（音声及び動画）、ストリーム・パケット化、メディア・ストリーム同期化、及び制御メッセージ・フォーマットなどの呼信号制御を記述するＨ．２２５．０や、追加サービスを記述する提案Ｈ．４５０などの多くの他の提案を参照している。他の信号制御プロトコルとしては仕様書ＲＦＣ３２６１におけるＩＥＴＦによって仕様が定められているＳＩＰ（セッション開始プロトコル）である。ＲＦＣ３２６１は、多くのＳＩＰメッセージの仕様を定めており、それらのメッセージはＲＦＣ２３２７において仕様が定められているセッション記述プロトコル（ＳＤＰ）を伝送する。

現在、３ＧＰＰや３ＧＰＰ２（第３世代パートナーシップ・プロジェクト）などの電話通信コミュニティ内のイニシアチブは、電話通信サービスにおける次世代のパケット交換コアネットワークを特定している。３ＧＰＰにおけるコアネットワーク・ドメインは、ＩＭＳ（ＩＰマルチメディア・サブシステム）と呼ばれている。３ＧＰＰは、現在、ＩＭＳにおける多くの追加サービスのサポートを含む要求仕様（例えば、３ＧＰＰＴＳ２２．１７３）を立案している。追加サービスの一例には、複数のマルチメディア端末が関与し、各端末が種々のメディアタイプをサポートするマルチメディア電話会議（又は、グループ呼）がある。メディアタイプは、通常、ＭＩＭＥ標準規格（ＲＦＣ２０４６）に従って仕様が定められている。

さらに、オープン・モバイル・アライアンス（ＯＭＡ）は、ＰｏＣ（プッシュ・ツー・トーク・オーバ・セルラー）における標準規格を定義している。例えば、プッシュ・ツー・トーク・オーバ・セルラー（ＰｏＣ）−アーキテクチャ、ドラフトバージョン２．０−２００７年３月、オープン・モバイル・アライアンス、ＯＭＡ−ＡＤ＿ＰｏＣ−Ｖ２＿０−２００７０３２６−Ｄは、参照によりここに記載されているものとする。ＯＭＡ＿ＰｏＣ仕様書のセットは、マルチ・パーティの電話会議を含むモバイル・デバイス間のＩＰ接続及びＩＰベースの通信を可能にする３ＧＰＰ＿ＩＰマルチメディア・サブシステム（ＩＭＳ）及び３ＧＰＰ２マルチメディア・ドメイン（ＭＭＤ）の機能を含む、ＩＥＴＦ、３ＧＰＰ及び３ＧＰＰ２による多くの既存の仕様書を利用する。

ＳＩＰ信号制御を用いることによって複数の呼が確立され、制御されるＩＭＳなどの電話通信システムにおいて、遠隔の端末の機能を判定する方法は、ＩＥＴＦ＿ＲＦＣ３２６１に記述されるＯＰＴＩＯＮＳと呼ばれるＳＩＰメソッドを使用する。本方法は、ユーザ端末が他の端末の機能について当該他の端末又はプロキシ・サーバに対して問い合わせさせる。これは、サポートされる、メソッド、コンテンツタイプ、拡張機能、符号化などについての情報を、他のパーティに”発呼する（ｒｉｎｇｉｎｇ）”ことなく、探索することをクライアントに許容する。ＯＰＴＩＯＮＳの応答は、リモート・エンドのメディア・サポートを記述するＳＤＰを添付した、いわゆる２００＿ＯＫメッセージである。２００＿ＯＫ応答は、ＯＰＴＩＯＮＳの送信側において利用可能な他の機能を示す特徴タグを含んでもよい。

ＳＩＰにおける現在のＯＰＴＩＯＮＳメソッドに関する制限は、各ＯＰＴＩＯＮＳリクエストに対して１つのＯＰＴＩＯＮＳ応答のみに限定されていることである。マルチメディア電話会議において、この制限は、ユーザが全ての電話会議参加者の共通のサポートがどのようなものであるかを知りたいときに問題となる。例えば、５人の参加者が関与する電話会議呼は、１人の参加者によって送信された単一のＯＰＴＩＯＮＳ要求に対して５つのＯＰＴＩＯＮＳ応答を戻すことができない。

上記問題は、本発明において、複数のユーザ端末（クライアント）間に位置するサーバを用いる方法を実装することによって解決される。当該方法は、それぞれの参加者におけるサポート機能（メディアタイプ、追加サービスなど）を収集し、サポート機能の共通セットを集約し、電話会議のサポートを表す単一の応答メッセージ（２００＿ＯＫ応答）において、それらの集約した情報を返送する。

本発明においては、グループ呼コンテキストとともに１つのサービス問い合わせメッセージ（例えば、ＯＰＴＩＯＮＳ要求）を送信し、当該メッセージを、グループ呼サーバなどのサーバにおいて終端させることにより問題を解決する。その後、サーバは、それぞれの参加者端末から受信した共通サポート機能の分析を行う。サーバは、選択的に、任意のシステム・ポリシー、グループ・ポリシー及び加入者ポリシーを分析できる。これらのポリシーは、所定のサポートを禁止することができるが、端末は非加入者機能に起因する機能をサポートする。全てのそれらのパラメータを分析した後に、サーバは、サポート機能についての情報であるＳＤＰ記述を含む集約した２００＿ＯＫ応答を形成する。サーバは、参加者の７５％が動画をサポートする場合の呼における可能性として、１つのポリシーが例えば動画を含むように決定することができる。

サービス問い合わせメッセージ（ＯＰＴＩＯＮＳ要求など）は、継続している会議呼の間に、又は、任意の継続している呼に関連することなく、送信されうる。

本解決手法の利点は、他のユーザ端末がどのような機能をサポートしているかを前もって知っていることによって電話会議呼が確立されうることである。したがって、多くの試験的でかつ誤った呼設定を必要としない。

他の利点は、電話会議呼に関与する各端末で利用可能な機能が端末上でユーザフレンドリな方法でユーザに対して提示されうることである。例えば、ディスプレイを有するモバイル電話機は、関与する端末ごとの機能を表示するアイコンを提示することができる。これは、電話会議をユーザに対してより魅力のあるものとし、最終的には、ネットワーク・オペレータにとって利得となるネットワークにおけるより高いトラフィック量を発生するであろう。

さらに他の利点は、当該サービスが市場に導入された場合に、本方法がマルチメディア・サービスの新たなシェアとともに拡大されうることである。

本発明の目的は、マルチメディア電話会議呼において、マルチメディア端末間における通信を単純化することにある。

以下では、最良の実施形態と添付の図面を参照して、本発明をより詳細に説明する。

本発明に係るグループ呼サーバにアクセス可能な端末のグループを示すブロック図である。本発明における方法に係るマルチメディア端末によってサポートされる機能を判定するステップを示すフローチャートである。多数のサブサーバに分割されたサーバを示すブロック図である。

図１は、サーバにアクセス可能な複数の端末１１１−１１４を含むグループ１１０と、グループ呼サーバ１００とを示す。グループ呼サーバ１００は、グループ１１０において、端末１１１からのＳＩＰ＿ＯＰＴＩＯＮＳ要求を受信する。サーバ１００は、さらに、ＳＩＰ＿ＯＰＴＩＯＮＳ要求１３１、１４１、１５１をグループ１１０の複数の他の端末１１２−１１４に同報送信する。

グループ呼サーバ１００は、グループ１１０における端末１１２−１１４の機能を格納するメモリ領域（キャッシュ）１０５を備える。

図１は、グループ１１０における端末１１１−１１４とグループ呼サーバ１００との間の情報フローも示している。

１）端末１（１１１）は、継続中のＳＩＰセッション内でＳＩＰ＿ＯＰＴＩＯＮＳ要求１２１を送信する。ＳＩＰ＿ＯＰＴＩＯＮＳ要求１２１は、グループ呼サーバ１００にアドレス指定されている。

２）グループ呼サーバ１００は、ＳＩＰ＿ＯＰＴＩＯＮＳ要求１３１を端末２（１１２）に対して送信する。

３）グループ呼サーバ１００は、ＳＩＰ＿ＯＰＴＩＯＮＳ要求１４１を端末３（１１３）に対して送信する。

４）グループ呼サーバ１００は、ＳＩＰ＿ＯＰＴＩＯＮＳ要求１５１を端末４（１１４）に対して送信する。

５）グループ呼サーバ１００は、端末２（１１２）から、例えば、ｍ＝ａｕｄｉｏ（音声）、ｍ＝ｖｉｄｅｏ（ビデオ）、ｍ＝ｍｅｓｓａｇｉｎｇ（メッセージング）をサポートすることを示すＳＩＰ＿２００＿ＯＫ応答１３２を受信する。

６）グループ呼サーバ１００は、端末３（１１３）から、例えば、ｍ＝ａｕｄｉｏ、ｍ＝ｖｉｄｅｏをサポートすることを示すＳＩＰ＿２００＿ＯＫ応答１４２を受信する。

７）グループ呼サーバ１００は、端末４（１１４）から、例えば、ｍ＝ａｕｄｉｏ、ｍ＝ｖｉｄｅｏ、ｍ＝ｍｅｓｓａｇｉｎｇをサポートすることを示すＳＩＰ＿２００＿ＯＫ応答１５２を受信する。

８）グループ呼サーバ１００は、例えば全ての参加者デバイスがサポートするビデオ（動画）ではあるが端末１（１１１）が用いることを制限する任意のシステム、グループ、又は、加入者ポリシーを検査する。その後、グループ呼サーバ１００は、共通セットの機能情報を有する、端末１（１１１）への共通ＳＩＰ＿２００＿ＯＫ応答１２２を生成する。上記例において、ＳＩＰ＿２００＿ＯＫ応答１２２は、ｍ＝ａｕｄｉｏ、及びｍ＝ｖｉｄｅｏの情報を有するＳＤＰを含むことになる。これは、端末２（１１２）及び端末４（１１４）がメッセージング機能をサポートしているものの、端末３（１１３）がサポートしていないためである。

９）端末１（１１１）は、ＳＩＰ＿２００＿ＯＫ応答１２２を受信すると、当該ＳＩＰ＿２００＿ＯＫ応答１２２に付加されたＳＤＰを解析する。端末１（１１１）がディスプレイを備えていれば、例えば、”動画追加”などのアイコンがディスプレイ上のソフトボタンとして強調表示される。当該ボタンを押下することにより、端末２−４（１１２−１１４）へ動画がストリーミング配信される。

本方法を使用することにより、端末１（１１１）が電話会議に関与する全ての他の端末２−４（１１２−１１４）の機能を認識する方法を提供することができる。

信号伝達（シグナリング）を保存するために、グループ呼サーバ１００は選択的に各端末１１２−１１４からの応答１３２、１４２、１５２をメモリ領域１０５に格納することができる。他の端末がＳＩＰ＿ＯＰＴＩＯＮＳ要求を送信すると、つまり、図１の構成において端末２（１１２）がＳＩＰ＿ＯＰＴＩＯＮＳ要求１７１を送信する場合、グループ呼サーバ１００は、端末１（１１１）に対して、端末２（１１２）へＳＩＰ＿２００＿ＯＫ応答１７３を送信する前にサーバ１００によって既に知られている端末３（１１３）からのＳＩＰ＿２００＿ＯＫ応答１４２及び端末４（１１４）からのＳＩＰ＿２００＿ＯＫ応答１５２を含む、ＳＩＰ＿ＯＰＴＩＯＮＳ要求１７２を送信するのみである。

図２は、本発明に係る方法においてグループ呼サーバ１００の処理手順を説明するフローチャートである。ステップ２０１において、グループ呼サーバ１００は、グループ１１０の端末１１１から第１のサービス問い合わせメッセージ１２１（ＯＰＴＩＯＮＳ要求など）を受信する。ステップ２０２において、サーバ１００は、グループ１１０の他の端末１１２−１１４の少なくとも１つに対して、第２のサービス問い合わせメッセージ（ＯＰＴＩＯＮＳ要求）を同胞送信する。ステップ２０３において、サーバ１００は、問い合わせた端末１１２−１１４のそれぞれから第１のサービス応答メッセージ（２００＿ＯＫメッセージなど）１３２、１４２、１５２を受信する。選択的に、サーバ１００は、端末１１２−１１４からの受信した全てのサービス応答メッセージ１３２、１４２、１５２をメモリ領域１０５に格納する。ステップ２０５において、サーバ１００は、受信したサービス応答メッセージ１３２、１４２、１５２の内容を解析し、ステップ２０６において、サービスの共通セットを決定（判定）する。その後、当該サービスの共通セットは、ステップ２０７において、サービス応答メッセージ（２００＿ＯＫメッセージ）において端末１１１に送信される。

図３は、アプリケーション、例えば、３ｇｐｐマルチメディア電話通信又はＯＭＡ＿ＰｏＣに従っていくつかのサーバに分割されたグループ呼サーバ３００を示す。図３は、アドホック・サーバ３１０と、多くのサブサーバ３１１−３１３とを含む。アドホック・サーバ３１０は、端末１１１からアクセス可能であり、サブサーバ３１１−３１３は、端末１１２−１１４からそれぞれアクセス可能である。

図３は、例えば、ＭＭｔｅｌ（マルチメディア電話機）アドホック・グループ呼、又は、１対１ＰｏＣセッション及びアドホックＰｏＣセッションに適用可能なマルチサーバ構成の一例である。

端末１１２−１１４を管理するサーバ３１１−３１３は、在圏ユーザのサブスクリプション及びサービスプロバイダのローカル・ポリシーに基づき、受信したサービス応答メッセージ（２００＿ＯＫ）３５１−３５３の内容を修正してもよい。

アドホック・サーバ３１０は、サブサーバ３１１−３１３から受信した応答３２２−３２４を結合し、端末１（１１１）へＯＰＴＩＯＮＳ応答３２１を送信する前に、サブスクリプション・オプション及びサービスプロバイダのローカル・ポリシーなどのグループ・ポリシーを適用してもよい。

本発明は、ここで説明した実施形態において、ＰｏＣ（プッシュ・ツー・トーク・オーバ・セルラ）に基本的に適用される。当業者には、３ＧＰＰマルチメディア電話、ＭＭｔｅｌアドホック・グループなどの多くの他のネットワーク・シナリオに本発明を適用できることを理解するであろう。

以下では、ＲＦＣ３２６１から抽出したＯＰＴＩＯＮメソッドの説明について記載する。

ＳＩＰメソッドＯＰＴＩＯＮＳは、ＵＡ（ユーザ・エージェント）に対して、他のＵＡ又はプロキシ・サーバにそれらの機能について問い合わせることを許容する。これは、ユーザに対して、他のパーティに対して”発呼”することなく、サポートされる、メソッド、コンテンツタイプ、拡張機能、コーデック等についての情報を探索させることを許容する。例えば、クライアントが取得ヘッダ・フィールドを、特定の宛先ＵＡＳ（ユーザ・エージェント・サーバ）サポートでないオプションのＩＮＶＩＴＥリストに挿入する前に、クライアントは、これがサポートされるヘッダ・フィールドにおいて戻されるかどうかを確かめるために、ＯＰＴＩＯＮＳとともに宛先ＵＡＳを問い合わせることができる。全てのＵＡがＯＰＴＩＯＮＳメソッドをサポートするべきである。

ＯＰＴＩＯＮＳ要求の対象は、リクエスト−ＵＲＩによって特定される。リクエスト−ＵＲＩは、他のＵＡ又はＳＩＰサーバを特定することができる。ＯＰＴＩＯＮＳがプロキシ・サーバにアドレス指定される場合、リクエストＵＲＩは、ユーザ側ではなく、登録要求として設定される方法と同様に設定される。

或いは、マックス・フォーワードにおけるゼロのヘッダ・フィールド値を有するＯＰＴＩＯＮＳ要求を受信するサーバは、リクエストＵＲＩに関わらず当該応答に対して応答してもよい。

当該動作は、ＨＴＴＰ／１．１で共通である。当該動作は、増加したマックス・フォーワード値を有する一連のＯＰＴＩＯＮＳ要求を送信することによって個々のホップ・サーバの機能を検査するために”トレースルート”機能として使用されうる。

通常のＵＡ動作の場合には、トランザクション・レイヤは、ＯＰＴＩＯＮＳの応答が発生しない場合に、タイムアウト・エラーを戻すことができる。これは、対象が到達不可能であるため利用可能でないということを示してもよい。

ＯＰＴＩＯＮＳ要求は、ダイアログ内で利用されうる機能でのピアを問い合わせるために、確立したダイアログの一部として送信されてもよい。

ＯＰＴＩＯＮＳ要求は、ＲＦＣ３２６１のセクション８．１．１に記載されるように、ＳＩＰ要求用の標準ルールを用いて構成される。

連絡ヘッダ・フィールドは、ＯＰＴＩＯＮＳ内に与えられてもよい。

受理ヘッダ・フィールドには、ＵＡＣ（ユーザ・エージェント・クライアント）が応答において受信することを望むメッセージ・ボディの種別を示す内容が含まれるべきである。一般的には、これは、ＳＤＰ（アプリケーション／ｓｄｐ）などのＵＡのメディア機能を記載するために用いられるフォーマットに設定される。ＯＰＴＩＯＮＳ要求への応答は、オリジナル要求におけるリクエストＵＲＩへ範囲付けられるべく想定されている。しかし、ＯＰＴＩＯＮＳが確立されたダイアログの一部としてのみ送信される場合には、さらなる要求がＯＰＴＩＯＮＳを生成したサーバによって受信されることが保証される。

＜ＯＰＴＩＯＮＳ要求の一例＞
ＯＰＴＩＯＮＳｓｉｐ：ｃａｒｏｌ＠ｃｈｉｃａｇｏ．ｃｏｍＳＩＰ／２．０
Ｖｉａ：ＳＩＰ／２．Ｏ／ＵＤＰｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７
Ｍａｘ−Ｆｏｒｗａｒｄｓ：７０
Ｔｏ：＜ｓｉｐ：ｃａｒｏｌ＠ｃｈｉｃａｇｏ．ｃｏｍ＞
Ｆｒｏｍ：Ａｌｉｃｅ＜ｓｉｐ：ａｌｉｃｅθａｔｌａｎｔａ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７４
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１０
ＣＳｅｑ：６３１０４ＯＰＴＩＯＮＳ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ａｌｉｃｅ＠ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ＞
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
ＯＰＴＩＯＮＳへの応答は、ＲＦＣ３２６１のセクション８．２．６に議論されているようにＳＩＰ応答における標準ルールを用いて構成される。選択された応答コードは、要求がＩＮＶＩＴＥであるように選択されるのと同様である必要がある。つまり、２００（ＯＫ）は、ＵＡＳが呼を受理する準備ができていれば戻されるであろうし、４８６（ＢｕｓｙＨｅｒｅ）は、ＵＡＳがビジー状態等であれば戻されるであろう。これは、使用するＯＰＴＩＯＮＳ要求がＵＡＳの基本状態を判定することを許容し、ＵＡＳがＩＮＶＩＴＥ要求を受理するか否かの指標となりうる。

ダイアログ内で受信されるＯＰＴＩＯＮＳ要求は、１つの構成された外部のダイアログと同一である２００（ＯＫ）応答を生成し、ダイアログ上で何らかの影響はない。

このＯＰＴＩＯＮＳの使用は、ＯＰＴＩＯＮＳとＩＮＶＩＴＥ要求とを扱うプロキシの差異によって制限される。分岐したＩＮＶＩＴＥは複数の２００（ＯＫ）応答となる一方で、分岐したＯＰＴＩＯＮＳは、非ＩＮＶＩＴＥハンドリングを用いるプロキシによって扱われるため、単一の２００（ＯＫ）応答のみとなる。規範的な詳説としてＲＦＣ３２６１のセクション１６．７を参照のこと。

ＯＰＴＩＯＮＳへの応答がプロキシ・サーバによって生成されれば、プロキシは、サーバの機能を問い合わせる２００（ＯＫ）を戻す。

応答にはメッセージ・ボディが含まれない。

許可（Ａｌｌｏｗ）、受理（Ａｃｃｅｐｔ）、受理符号化（Ａｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇ）、受理言語（Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ）及びサポート（Ｓｕｐｐｏｒｔｅｄ）のヘッダ・フィールドはＯＰＴＩＯＮＳへの２００（ＯＫ）応答で提示されるべきである。応答がプロキシによって生成されれば、許可ヘッダ・フィールドは、プロキシがメソッドを知らないため、不明瞭なものとして削除される。連絡ヘッダ・フィールドは、２００（ＯＫ）に提示されてもく、３ｘｘ応答と同様の動作を行う。つまり、これらは、代替名と、ユーザにたどり着くためのメソッドとを記載してもよい。

メッセージ・ボディは、ＯＰＴＩＯＮＳ要求の受理ヘッダ・フィールドによって判定される種別で送信されてもよい（受理ヘッダ・フィールドが提示されなければ、アプリケーション／ｓｄｐがデフォルトとなる。）。種別がメディア機能を記載するものを含めば、ＵＡＳは、当該目的における応答のボディを含むべきである。アプリケーション／ｓｄｐのボディ等の構成の詳細については、ＲＦＣ３２６１に記載されている。

＜ＵＡＳによって生成されるＯＰＴＩＯＮＳ応答の一例＞
ＳＩＰ／２．０２００ＯＫ
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫｈｊｈｓ８ａｓｓ８７７；ｒｅｃｅｉｖｅｄ＝１９２．０．２．４
Ｔｏ：＜ｓｉｐ：ｃａｒｏｌ＠ｃｈｉｃａｇｏ．ｃｏｍ＞；ｔａｇ＝９３８１０８７４
Ｆｒｏｍ：Ａｌｉｃｅ＜ｓｉｐ：ａｌｉｃｅΘａｔｌａｎｔａ．ｃｏｍ＞；ｔａｇ＝１９２８３０１７７４
Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１０
ＣＳｅｑ：６３１０４ＯＰＴＩＯＮＳ
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｃａｒｏｌ＠ｃｈｉｃａｇｏ．ｃｏｍ＞
Ｃｏｎｔａｃｔ：＜ｍａｉｌｔｏ：ｃａｒｏｌ＠ｃｈｉ．ｃａｇｏ．ｃｏｍ＞
Ａｌｌｏｗ：ＩＮＶＩＴＥ，ＡＣＫ，ＣＡＮＣＥＬ，ＯＰＴＩＯＮＳ，ＢＹＥ
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ａｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇ：ｇｚｉｐ
Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ：ｅｎ
Ｓｕｐｐｏｒｔｅｄ：ｆｏｏ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：２７４
（ＳＤＰｎｏｔｓｈｏｗｎ）
上記ＯＰＴＩＯＮＳ応答の一例は、上述した要求に対応する。

Claims

グループ（１１０）を構成する複数のマルチメディア端末（１１１−１１４）によってサポートされるマルチメディア機能を判定する電話通信ネットワークにおける方法であって、
第１のマルチメディア端末（１１１）から第１のサービス問い合わせメッセージ（１２１）を受信するステップ（２０１）と、
前記グループ（１１０）における他の前記マルチメディア端末（１１２−１１４）の少なくとも１つに対して、第２のサービス問い合わせメッセージ（１３１、１４１、１５１）を送信するステップと（２０２）、
前記他のマルチメディア端末（１１２−１１４）から、前記第２のサービス問い合わせメッセージ（１３１、１４１、１５１）に対する応答として、第１のサービス応答メッセージ（１３２、１４２、１５２）を受信するステップ（２０３）と、
前記第１のサービス応答メッセージ（１３２、１４２、１５２）において受信した機能をメモリ領域（１０５）に格納するステップ（２０４）と、
前記受信した機能を解析するステップ（２０５）と、
機能の共通セットを判定するステップ（２０６）と、
前記第１のマルチメディア端末（１１１）に対して、前記第１のサービス問い合わせメッセージ（１２１）に対する応答として、前記機能の共通セットを含む第２のサービス応答メッセージ（１２２）を送信するステップ（２０７）と
を含み、
前記他のマルチメディア端末（１１２−１１４）の何れかからサービス問い合わせメッセージを受信すると、前記メモリ領域（１０５）に格納された前記受信した機能と、前記第１のマルチメディア端末（１１１）に問い合わせて得た機能とに基づいて機能の共通セットを判定することを特徴とする方法。
前記機能の共通セットを判定する前記ステップ（２０６）は、さらに、ポリシーを適用するステップを含むことを特徴とする請求項１に記載の方法。
前記ポリシーは、システムポリシー、グループ・ポリシー、及び加入者ポリシーの少なくとも１つであることを特徴とする請求項２に記載の方法。
第２のマルチメディア端末（１１２）から第３のサービス問い合わせメッセージ（１７１）を受信するステップと、
前記第１のマルチメディア端末（１１１）に対して、第４のサービス問い合わせメッセージ（１７２）を送信するステップと、
前記第１のマルチメディア端末（１１１）から、前記第４のサービス問い合わせメッセージ（１７２）に対する応答として、第３のサービス応答メッセージ（１２１）を受信するステップと、
前記メモリ領域（１０５）に格納された前記受信した機能とともに、前記第３のサービス応答メッセージ（１２１）において受信した機能を解析するステップと、
第２の機能の共通セットを判定するステップと、
前記第２のマルチメディア端末（１１２）に対して、前記第３のサービス問い合わせメッセージ（１７１）に対する応答として、前記第２の機能の共通セットを含む第４のサービス応答メッセージ（１７３）を送信するステップと
をさらに含むことを特徴とする請求項１に記載の方法。
前記サービス問い合わせメッセージ（１２１、１３１、１７１）は、ＳＩＰ＿ＯＰＴＩＯＮＳ要求であり、
前記サービス応答メッセージ（１２２、１３２、１７２）は、ＳＩＰ＿２００＿ＯＫ応答であることを特徴とする請求項３又は４に記載の方法。
前記グループ（１１０）の前記マルチメディア端末（１１１−１１４）は、マルチメディア電話会議呼に従事していることを特徴とする請求項１乃至５の何れか１項に記載の方法。
複数のマルチメディア端末（１１１−１１４）を備えるグループ（１１０）からアクセス可能な電話通信ネットワークにおけるマルチメディア・アプリケーション・サーバ（１００）であって、
第１のマルチメディア端末（１１１）から受信したサービス問い合わせメッセージ（１２１）に応じて、前記グループ（１１０）における第２の前記マルチメディア端末（１１２−１１４）の少なくとも１つからの機能を収集し、収集した機能をメモリ領域（１０５）に格納し、
前記収集した機能を解析して、機能の共通セットを判定し、
前記第１のマルチメディア端末（１１１）に対して、前記機能の共通セットを含むサービス応答メッセージ（１２２）を戻す
ように構成され、
さらに、前記第２のマルチメディア端末（１１２−１１４）の何れかからサービス問い合わせメッセージを受信すると、前記メモリ領域（１０５）に格納された前記受信した機能と、前記第１のマルチメディア端末（１１１）に問い合わせて得た機能とに基づいて機能の共通セットを判定するように構成されることを特徴とするマルチメディア・アプリケーション・サーバ（１００）。
前記機能の共通セットを判定する際に、ポリシーを適用するようにさらに構成されることを特徴とする請求項７に記載のマルチメディア・アプリケーション・サーバ（１００）。
少なくとも１つの他のマルチメディア・アプリケーション・サーバ（３１０−３１３）と接続可能にさらに構成されることを特徴とする請求項７又は８に記載のマルチメディア・アプリケーション・サーバ（１００）。
請求項９に記載の複数のマルチメディア・アプリケーション・サーバ（３１０−３１３）が互いに接続されたシステム（３００）。
前記マルチメディア・アプリケーション・サーバ（３１０−３１３）がアプリケーションに依存した構成で互いに接続されることを特徴とする請求項１０に記載のシステム（３００）。
１つの前記マルチメディア・アプリケーション・サーバがアドホック・サーバ（３１０）であり、
他の前記マルチメディア・アプリケーション・サーバが前記アドホック・サーバ（３１０）に接続されるサブサーバ（３１１−３１３）であり、
前記アドホック・サーバ（３１０）は、さらに、前記サブサーバ（３１１−３１３）から受信されたサービス応答メッセージ（３２２−３２４）を結合するように構成されることを特徴とする請求項１１に記載のシステム（３００）。