JP2008506303A - マルチメディア通信システムにおいて異なったサービスを提供する方法および装置 - Google Patents

Abstract

ＳＩＰのようなセッション開始プロトコルを使用する従来のマルチメディア通信システムにおいて、継続中のマルチメディア・カンバセーション中にサービス変更を行う（例えば新たなメディアタイプを追加する）と、クライアントおよびサーバ双方に、かなりのプロセッサ負荷がかかり遅延が生じる。本発明は、異なるシグナリングチャネル（１４１、１４２）において、セッションシグナリングをメディア制御シグナリングから分離し、各サービス変更においてＳＩＰセッションの再確立の必要性を除去することにより、この問題を解決する。アプリケーションサーバ（１２０）は、マルチメディア・カンバセーションに関与する各マルチメディア・クライアント（１１０）によってサポートされる全てのメディアタイプを保持する。１つまたはいくつかの他のマルチメディア・クライアントと異なるメディアタイプで１つまたはいくつかのメディアストリームを送ることをリクエストする各マルチメディア・クライアント（１１０）は、プリケーションサーバ（１２０）のみとネゴシェーションすればよい。本発明は、ネットワーク遅延を著しく低減でき、ユーザは、サービス変更を速く行うことができると認識できる。本発明は、種々のマルチメディア・カンファレンス・アプリケーションに重要である。

Description

本発明は、マルチメディア通信システムにおいて異なったサービスを提供する方法および装置に関する。

現在、３ＧＰＰおよび３ＧＰＰ２（第３世代パートナーシップ・プロジェクト）のような電気通信界では、電気通信サービスのための次世代パケット・スイッチ・コアネットワークの詳細を決めようとしている。コアネットワーク・ドメインは、３ＧＰＰでは、ＩＭＳ（ＩＰマルチメディア・サブシステム）と呼ばれ、３ＧＰＰ２では、ＭＭＤ（マルチメディア・ドメイン）と呼ばれる。

ＩＭＳドメインとＭＭＤドメインとの類似点は、コール、すなわちセッションをセットアップするためのシグナリングが、ＳＩＰ（セッション開始プロトコル）（ＩＥＴＦ ＲＦＣ ３２６１）を使用して行われることにある。マルチメディア・サービスは、ＳＤＰ（セッション記述プロトコル）（ＩＥＴＦ ＲＦＣ ２３２７）によって記述される部分も含むＳＩＰメッセージを使用してセットアップされる。セッションまたはコールを開始するマルチメディア・クライアント（端末）は、サービスがメッセージのＳＤＰパート中で使用する全てのメディアタイプ（例えば、画像、音声等）を記述しなければならない。メディアタイプは、コアネットワーク・ドメイン中のアプリケーションサーバを介して、コールされたマルチメディア・クライアントと、ＳＩＰメッセージ交換においてネゴシェーションされる。

メディアは、典型例では、ＲＴＰ（リアルタイム伝送プロトコル）（ＩＥＴＦ ＲＦＣ ３５５０）を使用するＩＰで送られるが、他の伝送およびアプリケーションも使用できる。

ＩＰベースのネットワークを使用すると、サービス変更を行うことができる。サービス変更により、アクティブ・セッションの間に、マルチメディア・サービスに、同一または異なったタイプの１つまたはいくつかのメディアストリームを付加することができ、あるいは、アクティブ・セッションの間に、マルチメディア・サービスから、同一または異なったタイプの１つまたはいくつかのメディアストリームを除去することができる。サービス変更は、例えば、継続中のコールの間、現在のＶｏＩＰ（Ｖｏｉｃｅ（音声） ｏｖｅｒ ＩＰ）ストリームに画像ストリームを付加するか、または現在のＶｏＩＰストリームから画像ストリームを除去することを欲するユーザにより開始される。

ＶｏＩＰ内のサービス変更は、ＳＩＰメッセージを使用するネゴシェーション手順として説明されている。例示すると、クライアントは、まず、ＶｏＩＰコールを開始するために、ＳＩＰメッセージを送信する。このメッセージは、典型例では、ＳＩＰ ＩＮＶＩＴＥ（招待）メッセージである。ＳＩＰ ＩＮＶＩＴＥメッセージは、使用する音声コーデック（ｃｏｄｅｃ）の説明を含むＳＤＰを含んでいる。その後、ユーザは、ｒｅ−ＩＮＶＩＴＥ（再招待）メッセージとも呼ばれる別のＳＩＰ ＩＮＶＩＴＥ（招待）メッセージを送信して、セッションに画像ストリームを付加しようとする。ｒｅ−ＩＮＶＩＴＥメッセージ中では、音声コーデックの説明と画像コーデックの説明とがともに、ＳＤＰによって記述される。

ＩＭＳ／ＭＭＤフレームワーク内での概念は、セルラー・ネットワーク上でのプッシュ・トゥ・トーク（Ｐｕｓｈ−ｔｏ−Ｔａｌｋ）（ＰｏＣ）である。この概念により、携帯電話ユーザは、他の携帯電話ユーザのグループと、ハーフ・デュープレックス・モードで、ＩＰ上でウォーキートーキー（ｗａｌｋｉｅ−ｔａｌｋｉｅ）のように通信を行うことができる。セルラー・ネットワーク中のＩＰを使用する１つの利点は、ネットワーク・リソースをより効率的に使用できることである。ネットワーク・リソースは、コール・セッション全体の間ではなく、話している期間（ｔａｌｋ ｓｐｕｒｔ）の間のみ使用される。上述のコール・セッションは、ＳＩＰを使用して確立され、音声を伝送するメディア・チャネルは、ＲＴＰを使用する。ＰｏＣは、ウォーキートーキー風を実現するために、特定のコール制御機能を必要とする。例えば、メディア・チャネルが空いている（ｉｄｌｅ）ときに、ユーザは、（グループ内の他のユーザとの話を開始するために）携帯電話上のボタンを押すことにより、このチャネルのアクセスをリクエストできる。ユーザがボタンを放すと、メディア・チャネルは空きになり、グループ内の他のユーザがこのチャネルのアクセスをリクエストできる。このメカニズムは、「発言権（ｆｌｏｏｒ）を制御すること」に係わるので、「発言権制御（ｆｌｏｏｒ ｃｏｎｔｒｏｌ）」と呼ばれる。ＰｏＣに対してグローバルな相互に動作可能な規格を提供するために、電気通信界は、この分野で多数の仕様書（Ｓｐｅｃｉｆｉｃａｔｉｏｎ）を提供してきた。一例が、ＰｏＣリリース１．０仕様書「ＰｏＣユーザ・プレイン（ＰｏＣ Ｕｓｅｒ Ｐｌａｎｅ）；伝送プロトコル（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌｓ）」であり、これが、ＲＴＰ制御プロトコル（ＲＴＣＰ）を使用するメディア・チャネル中の発言権制御メカニズムについて詳細に説明している。しかし、発言権制御メカニズムは、サービス変更について説明しているわけではない。

マルチメディア・カンバセーションにおいてサービス変更のために帯域外シグナリングを使用する（例えば、ＳＩＰ／ＳＤＰ）問題点は、各シグナリングメッセージが多数の中間ネットワーク・ノード（ＳＩＰコア）を通過することである。ＳＩＰ／ＳＤＰプロトコルは、また、多くのメッセージを使用する。何故なら、これらのメッセージ中のコンテントが、２進符号化されたものの代わりに、「人間読取可能」ＡＳＣＩＩシンタックスを使用するからである。ＳＩＰ／ＳＤＰプロトコルでは、また、サービス変更毎に、進行中のセッションの再確立が必要である。これら全ての要因のため、不必要な遅延が生じ、プロセッサの負荷が高くなる。

本発明は、まず、シグナリングを、２つのプレイン、すなわち、セッションシグナリングプレインと、メディア制御シグナリングプレインとに分離することにより、上記問題を解決する。

セッションシグナリングプレインは、セッション制御のためのシグナリング（例えば、先行技術として知られているＳＩＰシグナリングメッセージを使用する）を含む。セッションシグナリングは、セッションシグナリングチャネル上を伝送される。メディア制御シグナリングプレインは、サービス変更、発言権制御等として、メディア制御シグナリングを含む。メディア制御シグナリングは、セッションシグナリングチャネルから分離したメディア制御チャネル上を伝送される。メディア制御チャネルは、メディア・チャネル内の帯域内にインプリメントされるか、メディア・チャネルに密接に関連した別個のチャネルを使用してインプリメントされる。

本発明は、また、中間アプリケーションサーバを関与させる新規なメディアタイプ・ネゴシェーション手順を提供する。このアプリケーションサーバは、セッションに関与する各マルチメディア・クライアントがサポートできるメディアタイプに関する情報を収集する。アプリケーションサーバは、収集した情報から、最大のインターオペラビリティを達成するために、各マルチメディア・クライアントに使用を許容（ａｌｌｏｗ）するメディアタイプを決定できる。

２つまたはそれ以上のマルチメディア・クライアントを含むセッションを確立することを望むマルチメディア・クライアント（セッション開始クライアント）は、マルチメディア・クライアントを１つ１つ招待（Ｉｎｖｉｔｅ）する。セッションは、招待するマルチメディア・クライアントへのアドレス付きで、招待メッセージを、帯域外シグナリングチャネルを介して中間アプリケーションサーバに送ることにより、確立される。招待メッセージは、また、セッション開始クライアントがサポートできるメディアタイプのセットを含む。

アプリケーションサーバは、招待するマルチメディア・クライアントに、セッション招待メッセージを転送する。招待されたマルチメディア・クライアントが、招待を許諾すると、該マルチメディア・クライアントがサポートできるメディアタイプのセットを、セッション応答メッセージ中で、知らせることにより応答する。アプリケーションサーバは、セッション確立が成功したことを述べたセッション応答メッセージで、セッション開始クライアントに応答する。

他のマルチメディア・クライアントに対する各招待手順では、アプリケーションサーバは、これら他のマルチメディア・クライアントのためにサポートされるメディアタイプに関する情報を収集する。

セッションに関与するマルチメディア・クライアントの１つ（以下、リクエストまたは送信を行うマルチメディア・クライアントという）が、１つまたはそれ以上の（例えば、音声、画像等の）メディアタイプ付きのマルチメディア・ストリームを送りたいときには、該マルチメディア・クライアントは、「リクエスト（ｒｅｑｕｅｓｔｅｄ）」メディアタイプのセットを含む第１メディア・リクエストを送る。「リクエスト」メディアタイプのセットは、リクエスト・マルチメディア・クライアントのためにサポートされたメディアタイプのセットに等しいかそのサブセットである。セッションに関与する全てのマルチメディア・クライアントがサポートできるメディアタイプに関する収集情報から、アプリケーションサーバは、リクエスト・マルチメディア・クライアントに対して、第１メディア許可（ｇｒａｎｔ）中で、「許容（ａｌｌｏｗｅｄ）」メディアタイプのセットを許可する。

第１メディア・リクエストおよび第１メディア許可は、セッション招待メッセージおよびセッション応答メッセージ中で、またはセッションシグナリングチャネルとは異なるメディア制御チャネル上の別個のメディア制御メッセージ中で伝送される。このメディア制御チャネルは、別個のチャネルとしてインプリメントされるか、メディア・チャネル内の帯域内にインプリメントされる。メディア制御メッセージは、従来技術のセッション制御メッセージに使用されているＡＳＣＩＩシンタックスではなく、短い２進シンタックスを使用できる。

これにより、今や、リクエスト・マルチメディア・クライアントは、受信を行うマルチメディア・クライアントに対して、アプリケーションサーバを介して、メディア・チャネル上で、（「許容」メディアタイプのセットに従って）メディアストリームの送信を行うことができる。アプリケーションサーバは、（必要ならば）メディアストリームを複写し、受信を行うマルチメディア・クライアントに、それを再送信する。

セッションの間のある時点において、リクエスト・マルチメディア・クライアントのユーザが、例えば、音声のみを送信していたのを、音声および画像を送信するように変更するため、受信を行うマルチメディア・クライアントに対して、サービス変更を行うことを希望したとする。

リクエスト・マルチメディア・クライアントは、新たな「リクエスト」メディアタイプのセットを含む新たなメディア・リクエストを、アプリケーションサーバに送信する。アプリケーションサーバは、リクエスト・マルチメディア・クライアントに対して、新たなメディア許可の中で、新たな「許容」メディアタイプのセットを許可する。

これにより、今や、リクエスト・マルチメディア・クライアントは、受信を行うマルチメディア・クライアントに対して、アプリケーションサーバを介して、メディア・チャネル上で、（新たな「許容」メディアタイプのセットに従って）メディアストリームの送信を行うことができる。

新たなメディア・リクエストおよび新たなメディア許可は、メディア制御メッセージ中で伝送される。

例え、受信を行う全てのマルチメディア・クライアントが特定のメディアタイプをサポートしていなくても、アプリケーションサーバは、リクエスト・マルチメディア・クライアントがこの特定のメディアタイプを送信することを許可する。この場合、アプリケーションサーバは、受信を行うマルチメディア・クライアントに、この特定のメディアタイプを、再送信する代わりに、この特定のメディアタイプに関連するメディアフローを終わらせる（ｔｅｒｍｉｎａｔｅ）。

アプリケーションサーバは、また、アプリケーションサーバ等によって強制されるローカル・ポリシーや加入者情報のようなさらなるパラメータに応じて、リクエスト・マルチメディア・クライアントに対して、異なったセットの「許容」メディアタイプを許可できる。

本発明は、セッション制御プロトコルとは別個でＳＩＰコアを通過しないメディア制御プロトコルを使用することにより、ネットワーク中のシグナリング遅延を低減することができる。また、本発明によれば、サービス変更毎に、継続中のセッションを再確立する必要がないので、シグナリングを著しく減少させることができる。シグナリングおよび遅延の低減、ならびにサービス変更手順の迅速化を、ユーザは認識することができる。

以下、添付の図面を参照して、好適な実施形態と共に、本発明をさらに詳細に説明する。

図１には、少なくとも本発明の一実施例がインプリメントされたマルチメディア通信システムの機能アーキテクチャが示されている。このアーキテクチャは、図１では携帯ビデオ電話として例示されている複数のマルチメディア・クライアント１１０、アプリケーションサーバ１２０およびネットワーク１３０を含むものである。アプリケーションサーバ１２０は、セッションシグナリングユニット１２１およびメディア・リソース・ユニット１２２のような複数の機能エンティティを含んでいる。セッションシグナリングユニット１２１は、マルチメディア・クライアント１１０からＳＩＰシグナリングメッセージを受信するとともにマルチメディア・クライアント１１０にＳＩＰシグナリングメッセージを送信するシグナリングインターフェイス１２３を有する。ＳＩＰシグナリングプロトコルは、セッションシグナリングチャネル１４１上を伝送される。メディア・リソース・ユニット１２２は、メディア制御シグナリングをマルチメディア・クライアント１１０に送信し、メディア制御シグナリングをマルチメディア・クライアント１１０から受信するメディア制御インターフェイス１２４を有する。メディア制御シグナリングは、メディア制御チャネル１４２を通して伝送される。メディアストリーム（メディアフロー）は、メディア・チャネル１４３を通して伝送される。メディア・リソース・ユニット１２２は、メディアストリームをマルチメディア・クライアント１１０に送信し、メディアストリームをマルチメディア・クライアント１１０から受信するメディア・インターフェイス１２５を有する。メディア・リソース・ユニット１２２は、必要ならば、複写ユニット１２６を使用して、マルチメディア・クライアント１１０から受信したメディアストリームを、マルチメディア・カンバセーションに関与する他のマルチメディア・クライアントに複写する。メディア・リソース・ユニット１２２は、また、マルチメディア・クライアント１１０から受信したメディアストリーム中のメディアタイプが特定の他のマルチメディア・クライアントによってサポートされていないときに、当該メディアタイプを終わらせることができる。アプリケーションサーバ１２０は、また、セッションシグナリングおよびメディア制御シグナリングを処理するプロセッサ・ロジック１２８と、各マルチメディア・クライアント１１０のためにサポートされているメディアタイプのセットを記憶する記憶領域１２７とを有する。

セッションシグナリングチャネル１４１は、ネットワーク１３０中の多数の異なる中間ノードを通ることができ、各ノードにおいて、セッションシグナリングメッセージが処理される。ＳＩＰシグナリングを処理する中間ノードは、これら全てを集めた総称として、ＳＩＰコア１３１と呼ばれる。メディア制御チャネル１４２およびメディア・チャネル１４３は、ともに、セッションシグナリングチャネル１４１から明確に分離されている。ただし、メディア制御チャネル１４２およびメディア・チャネル１４３は、同一チャネルに統合してもよい。

図２は、アプリケーションサーバ１２０から見たサービス変更のための典型的情報フローを示す。アプリケーションサーバ１２０は、第１のマルチメディア・クライアントからセッション招待メッセージ２０１を受信する。セッション招待メッセージは、第１マルチメディア・クライアントによってサポートされるメディアタイプのセットを含む。このセットは、アプリケーションサーバ１２０に記憶される（２０４）。アプリケーションサーバ１２０は、第２のマルチメディア・クライアントにセッション招待メッセージ２０２を送信する。第２のマルチメディア・クライアントは、招待を承諾すると、セッション応答メッセージ２０３を送信する。このセッション応答メッセージ２０３は、第２マルチメディア・クライアントによってサポートされるメディアタイプのセットを含む。このセットも、アプリケーションサーバ１２０に記憶される（２０４）。アプリケーションサーバ１２０は、セッション招待が成功したことを示すセッション応答メッセージ２０５を、第１マルチメディア・クライアント送信する。セッション招待手順は、第１のマルチメディア・クライアントによってセッションに招待された他のマルチメディア・クライアントのそれぞれについて、繰り返される。

セッションに関与するいずれかのマルチメディア・クライアント、すなわちリクエスト・マルチメディア・クライアントが、他のマルチメディア・クライアントに、マルチメディア・ストリーム（例えば、音声）を送りたいときには、リクエスト・マルチメディア・クライアントは、第１メディア・リクエスト２０６を送る。第１メディア・リクエスト２０６は、第１「リクエスト（ｒｅｑｕｅｓｔｅｄ）」メディアタイプのセットを含む。アプリケーションサーバ１２０は、他のマルチメディア・クライアントのためにサポートされたメディアタイプの知識があるので、アプリケーションサーバ１２０は、第１「リクエスト」メディアタイプのセットと、他のマルチメディア・クライアントによってサポートされたメディアタイプの全てのセットとを比較し（２０７）、第１「許容」メディアタイプのセットを有するメディア許可２０８で応答することにより、リクエストを許可する。リクエスト・マルチメディア・クライアントは、第１許容」メディアタイプのセットによるメディアタイプで、メディアストリーム（メディアフロー）を、メディア・チャネルを通して伝送できる。メディアストリーム（メディアフロー）は、アプリケーションサーバ１２０によって受信され（２０９）、（必要に応じて）複写され、他のマルチメディア・クライアントに再送信される（２１０）。カンバセーションの間、リクエスト・マルチメディア・クライアントが、（例えば、継続中の音声カンバセーションに映像を付加することにより）メディアストリーム（メディアフロー）を変更したいときには、リクエスト・マルチメディア・クライアントは、第２「リクエスト」メディアタイプのセットを含む第２メディア・リクエスト２１１を、アプリケーションサーバ１２０に送信する。アプリケーションサーバ１２０は、「第２リクエスト」メディアタイプのセットと、他のマルチメディア・クライアントによってサポートされたメディアタイプの全てのセットとを比較し（２１２）、第２メディア許可２１３でリクエストを許可する（２１３）。この第２メディア許可２１３は、第２「許容」メディアタイプのセットを含む。これにより、今や、リクエスト・マルチメディア・クライアントは、第２「許容」メディアタイプのセットによるメディアタイプで、変更（ｍｏｄｉｆｉｅｄ）メディアストリーム（メディアフロー）を、メディア・チャネルを通して伝送できる。このメディアストリーム（メディアフロー）は、アプリケーションサーバ１２０によって受信され（２１４）、（必要に応じて）複写され、他のマルチメディア・クライアントに再送信される（２１５）。

第１および第２メディア・リクエスト２０６および２１１ならびに第１および第２メディア許可２０８および２１３は、典型例では、メディア制御メッセージ中で伝送される。

図２は、典型的情報フローを示すものであり、種々の変更が可能である。リクエスト・マルチメディア・クライアントが第１マルチメディア・クライアントと同一であり、第１マルチメディア・クライアントが、招待手順の後、データの直接送信を開始したいときには、第１メディア・リクエスト２０６ならびに第１メディア許可２０８は、セッション招待メッセージ２０２およびセッション応答メッセージ２０５中に含ませることができる。このようにする代わりに、第１メディア・リクエスト２０６をセッション招待メッセージ中で送信し、第１メディア許可２０８を別個のメディア制御メッセージ中で送信することができる。

第１メディア・リクエスト２０６および第１メディア許可２０８は、「黙示」のメディア許可とすることができる。例えば、アプリケーションサーバ１２０は、（記憶されたマルチメディア・クライアント・サブスクリプション・データから、またはセッション招待メッセージ２０１中の他のパラメータを見ることにより）ＶｏＩＰサービスがリクエストされたことを知ると、第１メディア許可２０８は、第２マルチメディア・クライアントに向かうセッション招待メッセージ２０２、ならびに第１マルチメディア・クライアントに向かうセッション応答メッセージ２０５中に組み入れることができる。この例では、ＶｏＩＰカンバセーションは通常音声を使用して開始するので、第１メディア許可２０８は、メディアタイプ「音声」を含む。

メディアタイプの比較（２０７、２１２）に加えて、アプリケーションサーバ１２０は、例えば、アプリケーションサーバ１２０によって強制されるローカル・ポリシーやサブスクライバー情報のような他のパラメータに応じて、リクエスト・マルチメディア・クライアントに、「許容」メディアタイプの異なったセットを許可できる（２０８、２１３）。

図２に示され、上述したサービス変更手順は、もちろん、１つまたは２つのサービス変更イベントのみに限定されない。セッションの間、関与マルチメディア・クライアントのいずれのクライアントの都合の良いときに、いつでも、上述のメディア制御メッセージを使用して、サービス変更を、リクエストでき、繰り返し行うことができる。

再送信されるメディアストリーム（メディアフロー）中の特定のメディアタイプをサポートしないマルチメディア・クライアントのために、この特定のメディアタイプは、これらのクライアントに到達する前に、アプリケーションサーバ１２０中で、終わらせることができる。

図３および図４は、画像（例えば、ビデオ・クリプ）で内容が豊かになったＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）カンバセーションのためのセッション確立およびサービス変更の実施例を示す。この情報フローに関与するネットワーク・エンティティは、２つのユーザ端末、すなわちマルチメディア・クライアントである第１クライアント３１０および第２クライアント３５０、ＳＩＰコア１３１、ならびにアプリケーションサーバ１２０である。

マルチメディア・クライアント３１０および３５０は、ＳＩＰシグナリングおよびメディア制御シグナリングを使用してアプリケーションサーバ１２０と通信を行う。ＳＩＰシグナリングメッセージは、典型例においては、セッションシグナリングチャネル１４１上を伝送され、シグナリングネットワーク中の多数の中間ノードすなわちＳＩＰコア１３１によって処理される。メディア制御シグナリングは、ＳＩＰコアから分離され、メディア制御チャネル１４２上を伝送される。アプリケーションサーバ１２０は、マルチメディア・クライアント３１０および３５０からメディア・チャネル１４３を通して送られてくるメディアストリームを受信し再送信する。

図３には、第１クライアント３１０と第２クライアント３５０との間にセッションを確立する情報フローが示されている。図４は、サービス変更手順のための情報フローを示す。

第１クライアント３１０を使用するユーザは、第２クライアント３５０を使用する別のユーザとのマルチメディア・セッションの開始をリクエストする（３０１）。第１クライアント３１０は、ＳＩＰコア１３１に、ＳＩＰ ＩＮＶＩＴＥメッセージ３１１を送信する。ＳＩＰ ＩＮＶＩＴＥメッセージ３１１は、第１クライアント３１０がサポートできる全てのメディアタイプのセット（この例では、音声および画像）を含む。ＳＩＰ ＩＮＶＩＴＥメッセージ３１１は、また、第１リクエスト・メディアタイプのセット（この例では、音声のみ）も含む。ＳＩＰコア１３１は、ＳＩＰ１００試行メッセージ３１２で応答する。ＳＩＰ１００試行メッセージ３１２は、ＳＩＰ ＩＮＶＩＴＥメッセージ３１１がＳＩＰコア１３１によって受信されたこと、このセッションのためにある不特定のアクションがとられていることを示す。ＳＩＰコア１３１は、第１クライアント３１０から受信されたメディアタイプのセットを含むＳＩＰ ＩＮＶＩＴＥメッセージ３２１を、アプリケーションサーバ１２０に送信する。アプリケーションサーバ１２０は、ＳＩＰコア１３１へのＳＩＰ１００試行メッセージ３２２で応答する。アプリケーションサーバ１２０は、第１クライアント３１０から受信されたメディアタイプのセットを記憶し、ＳＩＰ ＩＮＶＩＴＥメッセージ３３１を、ＳＩＰコア１３１へ送信する。ＳＩＰコア１３１は、ＳＩＰ１００試行メッセージ３３２でアプリケーションサーバ１２０に応答し、ＳＩＰ ＩＮＶＩＴＥメッセージ３４１を第２クライアント３５０に送信する。第２クライアント３５０は、第２クライアント３５０のユーザに、到来コール指示３５１を発生する。ユーザがセッション招待を承諾すると（３５２）、第２クライアント３５０は、ＳＩＰ２００ＯＫメッセージ３４２をＳＩＰコア１３１を送信し、ＳＩＰコア１３１は、ＳＩＰ２００ＯＫメッセージ３３３をアプリケーションサーバ１２０に送信する。２つのＳＩＰ２００ＯＫメッセージ３４２および３３３は、第２クライアント３５０がサポートできる全てのメディアタイプのセット（この例では、音声および画像）を搬送し、このセットは、アプリケーションサーバ１２０に記憶される。アプリケーションサーバ１２０は、第１クライアント３１０および第２クライアント３５０によってそれぞれサポートされている全てのメディアタイプの２つのセットを比較する。第１クライアント３１０が音声のみで開始することをリクエストし、第２クライアント３５０が音声をサポートしているので、アプリケーションサーバ１２０は、第１許容メディアタイプのセット（この例では、音声のみ）を含むＳＩＰ２００ＯＫメッセージ３２３を送信する。ＳＩＰコア１３１は、この情報を、ＳＩＰ２００ＯＫメッセージ３２３中で、第１クライアント３１０に転送する。第１クライアント３１０は、ＳＩＰ ＡＣＫメッセージ３１４をＳＩＰコア１３１に送信し、ＳＩＰコア１３１は、ＳＩＰ ＡＣＫメッセージ３２４を、アプリケーションサーバ１２０に送信する。

これにより、今や、第１クライアント３１０は、ＲＴＰプロトコル３２５および３４３を使用して、アプリケーションサーバ１２０を介して、メディア・チャネル１４３を通して、第２クライアント３５０に向けて、音声送信を開始できる。

音声カンバセーションの間に、第１クライアント３１０のユーザが、音声に加えて、ライブ・ビデオクリップを、第２クライアント３５０に向けて送りたいときには、サービス変更が必要である。サービス変更のための情報フローは、図４に示されている。第１クライアント３１０のユーザがこのサービス変更をリクエストすると（４０１）、第１クライアント３１０は、音声および画像を送信することのリクエストを含むメディア制御メッセージ４１１を、アプリケーションサーバ１２０に送信する。第１クライアント３１０および第２クライアント３５０は、ともに、画像をサポートしているので、アプリケーションサーバ１２０は、このリクエストを、メディア制御メッセージ４１２で許可する。アプリケーションサーバ１２０は、また、サービス変更を示すメディア制御メッセージ４３１を、第２クライアント３５０に送信する。これにより、今や、第１クライアント３１０は、音声および画像双方のメディアストリーム４２１および４４１を、第２クライアント３５０に送信できる。

第１クライアント３１０のユーザが、画像ストリームを終了し音声ストリームのみを継続することをリクエストすると（４０３）、第１クライアント３１０は、映像ストリームを放棄することをリクエストするメディア制御メッセージ４１３をアプリケーションサーバ１２０に送信する。アプリケーションサーバ１２０は、新たなサービス変更を示すメディア制御メッセージ４３２を第２クライアント３５０に送信する。

これにより、今や、第１クライアント３１０は、第２クライアント３５０に向けて音声のみを送信する（４２２、４４２）。メディア制御メッセージ４１３は、１つのメディアタイプの放棄に関するものなので、アプリケーションサーバ１２０は応答メッセージを送る必要はない。

図５および図６には、本発明の別の好ましい実施例が示されている。図５および図６は、画像で内容が豊かになったＰｏＣ（セルラー上でのプッシュ・トゥ・トーク）のためのセッション確立およびサービス変更手順を示す。原理は、ＶｏＩＰ（図３および図４）と同じであるが、メディア制御シグナリングは、ＰｏＣおよびカンファランス・アプリケーションで知られている発言権制御手順に使用されているのと同じメッセージ中で搬送される。ＰｏＣコンテクスト（状況）における発言権制御により、基本的に、携帯電話のユーザが、単に携帯電話上のボタンを押すことによって、他の携帯電話ユーザのグループに共通の通信チャネルにハーフデュプレックス・アクセスをリクエストすることができる。

まず、図５を参照するに、第１ＰｏＣユーザが、その携帯電話のボタンを押したとする（５０１）。他の携帯電話とのセッションがまだ存在しなければ、このイベント５０１は、第１ＰｏＣクライアント５１０によるセッション開始プロセスをスタートさせ、第１ＰｏＣクライアント５１０は、ＳＩＰコア１３１に、ＳＩＰ ＩＮＶＩＴＥメッセージ５１１を送信する。ＳＩＰ ＩＮＶＩＴＥメッセージ５１１は、黙示の「発言権リクエスト」とみなされる。ＳＩＰ ＩＮＶＩＴＥメッセージ５１１は、第１ＰｏＣクライアント５１０がサポートできる全てのメディアタイプのセット（この例では、音声および画像）を含む。ＳＩＰ ＩＮＶＩＴＥメッセージ５１１は、また、第１リクエスト・メディアタイプのセット（この例では、音声のみ）も含む。ＳＩＰコア１３１は、ＳＩＰ１００試行メッセージ５１２で第１ＰｏＣクライアント５１０に応答する。ＳＩＰコア１３１は、ＳＩＰ ＩＮＶＩＴＥメッセージ５２１を、アプリケーションサーバ１２０に送信する。ＳＩＰ ＩＮＶＩＴＥメッセージ５２１は、第１ＰｏＣクライアント５１０から受信されたメディアタイプのセットを含む。アプリケーションサーバ１２０は、ＳＩＰコア１３１へのＳＩＰ１００試行メッセージ５２２で応答する。アプリケーションサーバ１２０は、第１ＰｏＣクライアント５１０がサポートできる全てのメディアタイプのセットを記憶し、ＳＩＰ ＩＮＶＩＴＥメッセージ５３１を、ＳＩＰコア１３１へ送信する。ＳＩＰコア１３１は、ＳＩＰ１００試行メッセージ５３２でアプリケーションサーバ１２０に応答し、ＳＩＰ ＩＮＶＩＴＥメッセージ５４１を第２ＰｏＣクライアント５５０に送信する。

第２ＰｏＣクライアント５５０は、ＳＩＰ２００ＯＫメッセージ５４２をＳＩＰコア１３１を送信し、ＳＩＰコア１３１は、ＳＩＰ２００ＯＫメッセージ５３３をアプリケーションサーバ１２０に送信する。２つのＳＩＰ２００ＯＫメッセージ５４２および５３３は、第２ＰｏＣクライアント５５０がサポートできる全てのメディアタイプのセット（この例では、音声および画像）を搬送し、このセットは、アプリケーションサーバ１２０に記憶される。アプリケーションサーバ１２０は、第１ＰｏＣクライアント５１０および第２ＰｏＣクライアント５５０によってそれぞれサポートされている全てのメディアタイプの２つのセットを比較する。第１ＰｏＣクライアント５１０が音声のみで開始することをリクエストし、第２ＰｏＣクライアント５５０が音声をサポートしているので、アプリケーションサーバ１２０は、ＳＩＰ２０２許諾（Ａｃｃｅｐｔｅｄ）メッセージ５２４を送信する。ＳＩＰコア１３１は、この情報を、ＳＩＰ２００許諾メッセージ５１３中で、第１ＰｏＣクライアント５１０に転送する。ＳＩＰ２０２許諾メッセージ５２４送信に関連して、アプリケーションサーバ１２０は、また、第１許容メディアタイプのセット（この例では、音声のみ）とともに、メディア・リクエスト・メッセージおよび発言権制御メッセージの組み合わせを含むメッセージ５２３を送信する。

第１ＰｏＣクライアント５１０は、ＳＩＰ ＡＣＫメッセージ５１４をＳＩＰコア１３１に送信し、ＳＩＰコア１３１は、ＳＩＰ ＡＣＫメッセージ５２５を、アプリケーションサーバ１２０に送信する。第１ＰｏＣクライアント５１０のユーザは、トーク（ｔａｌｋ）を開始することを可能にするトーク指示を受ける（５０２）。アプリケーションサーバ１２０は、発言権剥奪（ｆｌｏｏｒ Ｔａｋｅｎ）音声メッセージ５３４を第２ＰｏＣクライアント５５０送信し、第２ＰｏＣクライアント５５０のユーザは、聴取指示（ｌｉｓｔｅｎｉｎｇ Ｉｎｄｉｃａｔｉｏｎ）を受ける。

これにより、図６に示されているように、今や、第１ＰｏＣクライアント５１０は、ＲＴＰプロトコル６２１および６４１を使用して、アプリケーションサーバ１２０を介して、メディア・チャネル１４３を通して、第２ＰｏＣクライアント５５０に向けて、ハーフデュプレックス音声ストリームの送信を開始できる。

第１ＰｏＣクライアント５１０のユーザは、いつでも「発言権放棄」をすることができ、ＰｏＣボタンを解放することにより、他のＰｏＣクライアントにチャネルを利用可能にできる（６０２）。この場合、発言権放棄音声メッセージ６１１がアプリケーションサーバ１２０に送信される。アプリケーションサーバ１２０は、発言権が空いている（ｉｄｌｅ）を示すために、発言権空きメッセージ６３１を第２ＰｏＣクライアント５５０に送信する。第２ＰｏＣクライアント５５０のユーザは、第２ＰｏＣクライアント５５０において発言権空き指示６５１を受ける。

セッション中のあるとき、第１ＰｏＣクライアント５１０のユーザが、音声および画像の双方に関係するマルチメディア・バーストを送信するリクエストを行う（６０３）。これにより、第１ＰｏＣクライアント５１０は、発言権リクエスト音声および画像メッセージ６１２をアプリケーションサーバ１２０に送信する。アプリケーションサーバ１２０は、このリクエスト許可するときには、発言権剥奪（Ｆｌｏｏｒ Ｔａｋｅｎ）音声および画像メッセージ６３２を第２ＰｏＣクライアント５５０に送信し、発言権許可（Ｆｌｏｏｒ Ｇｒａｎｔｅｄ）音声および画像メッセージ６１３を第１ＰｏＣクライアント５１０に送信する。第２ＰｏＣクライアント５５０のユーザは、到来画像および音声コール指示６５２を第２ＰｏＣクライアント５５０で受け、第１ＰｏＣクライアント５１０のユーザは、トーク（Ｔａｌｋ）およびショー（Ｓｈｏｗ）指示６０４を第１ＰｏＣクライアント５１０で受ける。

これにより、今や、第１ＰｏＣクライアント５１０は、ＲＴＰプロトコル６２２および６４２を使用して、アプリケーションサーバ１２０を介して、メディア・チャネル１４３を通して、第２ＰｏＣクライアント５５０に向けて、ハーフデュプレックス音声および画像ストリームの送信を開始できる。

第１ＰｏＣクライアント５１０のユーザが、音声および映像ストリームの放棄をリクエストすると（６０５）、第１ＰｏＣクライアント５１０は、発言権放棄（Ｆｌｏｏｒ Ｒｅｌｅａｓｅ）音声および画像メッセージ６１４を、アプリケーションサーバ１２０に送信する。アプリケーションサーバ１２０は、発言権空き（Ｆｌｏｏｒ Ｉｄｌｅ）メッセージ６３３を、第２ＰｏＣクライアント５５０に送信する。第２ＰｏＣクライアント５５０のユーザは、第２ＰｏＣクライアント５５０において発言権空き指示６５３を受ける。今や、第１ＰｏＣクライアント５１０と第２ＰｏＣクライアント５５０との間のメディア・チャネルは、空いている（ｉｄｌｅ）。これにより、今や、「発言権」は、セッションに関与するいずれのクライアントでもリクエストできる。

以上、図示し説明した本発明の実施例は、２つのマルチメディア・クライアント間のサービス変更に関するものであるが、本発明は、上記実施例に限定されるわけではなく、任意の数のマルチメディア・クライアントが関与するサービス変更を可能にするものである。招待された新たなマルチメディア・クライアントに対しては、ＳＩＰ ＶＩＴＥメッセージが、アプリケーションサーバ１２０を介して、送信される。アプリケーションサーバ１２０が各招待されたクライアントから受信する各ＳＩＰ ２００ ＯＫメッセージに応じて、各招待されたクライアントによってサポートされ、これらのメッセージに含まれるメディアタイプのセットは、アプリケーションサーバ１２０に記憶される。セッションに関与する任意のマルチメディア・クライアント（リクエスト・マルチメディア・クライアント）がメディアストリームを送信するリクエストを送る（または「発言権」リクエストを送る）毎に、アプリケーションサーバ１２０は、他の関与する全てのマルチメディア・クライアントによってサポートされるメディアタイプ、ならびにその時間におけるメディア・チャネル１４３の利用可能性に基づいてこのリクエストを許可する。アプリケーションサーバは、セッションに関与する特定のマルチメディア・クライアントが特定のメディアタイプをサポートしていなくても、リクエスト・マルチメディア・クライアントがその特定のメディアタイプを送信するのを許可できる。この場合、アプリケーションサーバは、この特定のメディアタイプを特定のマルチメディア・クライアントに再送信するのではなく、アプリケーションサーバ内のこのメディアタイプによるこのメディアストリーム（メディアフロー）を終了する。

「メディアタイプ」という用語は、単に、音声、画像、イメージ等を意味するものではなく、例えば、音声、画像等を符号化／復号化する異なったアルゴリズムを使用する異なったタイプのコーデックをも意味する。

図１は、ネットワーク・エレメント、ならびに別個のシグナリングインターフェイスおよびメディア・インターフェイスを含む機能アーキテクチャを示すブロック図である。 図２は、サービス変更のための典型的情報フローを示す流れ図である。 図３は、ＶｏＩＰおよび画像を含む実施例中で音声セッションを確立するための情報フローを示す流れ図である。 図４は、ＶｏＩＰおよび画像を含む実施例中で確立された音声セッション中でサービス変更をリクエストする情報フローを示す図３の続きである流れ図である。 図５は、ＰｏＣおよび画像を含む実施例中でセッションを確立するための情報フローを示す流れ図である。 図６は、ＰｏＣおよび画像を含む実施例中で確立されたセッション中でサービス変更をリクエストする情報フローを示す図５の続きである流れ図である。

Claims (19)

1. アプリケーションサーバ（１２０）と、複数のマルチメディア・クライアント（１１０）とを含むマルチメディア通信システムにおいて異なったサービスを提供する方法であって、
   前記複数のマルチメディア・クライアントのうち第１マルチメディア・クライアントから、マルチメディア・カンバセーションの一部になるように前記複数のマルチメディア・クライアントのうち少なくとも第２マルチメディア・クライアントを招待するリクエストを受信するステップ（２０１）と、
   前記第１マルチメディア・クライアントから、前記第１マルチメディア・クライアントがサポートするメディアタイプのセットを受信するステップ（２０１）と、
   前記第２マルチメディア・クライアントに対して、前記マルチメディア・カンバセーションの一部になるよう招待するリクエストを送信するステップ（２０２）と、
   前記第２マルチメディア・クライアントから、前記第２マルチメディア・クライアントがサポートするメディアタイプのセットを受信するステップ（２０３）と、
   前記第１および第２マルチメディア・クライアントがサポートするメディアタイプのセットを記憶するステップ（２０４）と、
   前記複数のマルチメディア・クライアントのうち送信を行うものから、第１リクエスト・メディアタイプのセットに従って前記複数のマルチメディア・クライアントのうち少なくとも１つの受信を行うものに向けてメディアストリームを送信するリクエストを受信するステップ（２０６）であって、前記送信を行うマルチメディア・クライアントと、前記受信を行うマルチメディア・クライアントとは、全て、前記マルチメディア・カンバセーションの一部であるステップと、
   前記第１リクエスト・メディアタイプのセットと、前記各受信を行うマルチメディア・クライアントがサポートする各メディアタイプのセットそれぞれとを比較するステップ（２０７）と、
   前記送信を行うマルチメディア・クライアントに、第１許容メディアタイプのセットを送信するステップ（２０８）と、
   前記送信を行うマルチメディア・クライアントから、前記第１許容メディアタイプのセットに応じたメディアタイプを含む第１メディアストリームを受信するステップ（２０９）と、
   前記受信を行うマルチメディア・クライアントに、前記第１メディアストリームを再送信するステップ（２１０）と
   を含む方法。
2. 前記送信を行うマルチメディア・クライアントから、第２リクエスト・メディアタイプのセットに従って前記受信を行うマルチメディア・クライアントに向けてメディアストリームの送信を行うリクエストを受信するステップ（２１１）と、
   前記第２リクエスト・メディアタイプのセットと、前記各受信を行うマルチメディア・クライアントがサポートする各メディアタイプのセットとを比較するステップ（２１２）と、
   前記送信を行うマルチメディア・クライアントに、第２許容メディアタイプのセットを送信するステップ（２１３）と、
   前記送信を行うマルチメディア・クライアントから、前記第２許容メディアタイプのセットに応じたメディアタイプを含む第２メディアストリームを受信するステップ（２１４）と、
   前記受信を行うマルチメディア・クライアントに、前記第２メディアストリームを再送信するステップ（２１５）と
   を含むことを特徴とする請求項１記載の方法。
3. 前記第２マルチメディア・クライアントに対して前記マルチメディア・カンバセーションの一部になるよう招待する前記リクエストと、前記第１マルチメディア・クライアントがサポートするメディアタイプの前記セットとが、セッション招待メッセージ中で伝送されることを特徴とする請求項１記載の方法。
4. 前記第２マルチメディア・クライアントがサポートするメディアタイプの前記セットが、セッション応答メッセージ中で伝送されることを特徴とする請求項１記載の方法。
5. 前記第１リクエスト・メディアタイプのセットに従ってメディアストリームの送信を行うことを求める前記リクエストが、セッション招待メッセージ中で伝送されることを特徴とする請求項１記載の方法。
6. 前記第１許容メディアタイプのセットが、セッション応答メッセージ中で伝送されることを特徴とする請求項１記載の方法。
7. 前記第１リクエスト・メディアタイプのセットに従ってメディアストリームの送信を行うことを求める前記リクエストが、メディア制御メッセージ中で伝送されることを特徴とする請求項１記載の方法。
8. 前記第１許容メディアタイプのセットが、メディア制御メッセージ中で伝送されることを特徴とする請求項１記載の方法。
9. 前記第２リクエスト・メディアタイプのセットに従ってメディアストリームの送信を行うことを求める前記リクエストと、前記第２許容メディアタイプのセットが、メディア制御メッセージ中で伝送されることを特徴とする請求項２記載の方法。
10. 前記セッション招待メッセージおよび前記セッション応答メッセージは、セッションシグナリングチャネルで伝送され、メディア制御メッセージは、前記セッションシグナリングチャネルから分離されたメディア制御チャネルで伝送されることを特徴とする請求項３乃至９のいずれか一項に記載の方法。
11. 前記セッション招待メッセージおよび前記セッション応答メッセージは、ＳＩＰ（セッション開始プロトコル）の一部であることを特徴とする請求項３乃至６のいずれか一項に記載の方法。
12. 前記第１メディアストリームおよび前記第２メディアストリームが、メディア・チャネルで伝送されることを特徴とする請求項１または２に記載の方法。
13. 前記受信を行う特定のマルチメディア・クライアントのために前記送信を行うマルチメディア・クライアントから受信したメディアストリーム中の特定のメディアタイプは、該メディアタイプが前記受信を行う特定のマルチメディア・クライアントがサポートするメディアタイプのセットではないときに、終わらせることを特徴とする請求項１または２に記載の方法。
14. 前記第１および第２リクエスト・メディアタイプのセットのそれぞれは、等しいか、または前記送信を行うマルチメディア・クライアントによってサポートするメディアタイプのセットのサブセットであることを特徴とする請求項１または２に記載の方法。
15. マルチメディア通信システムにおけるアプリケーションサーバ（１２０）であって、
    （ａ）セッションシグナリングをシグナリングチャネル（１４１）を通してマルチメディア・クライアント（１１０）に送信し、セッションシグナリングをシグナリングチャネル（１４１）を通してマルチメディア・クライアント（１１０）から受信する少なくとも１つのシグナリングインターフェイス（１２３）と、
    （ｂ）メディア制御シグナリングをメディア制御チャネル（１４２）を通してマルチメディア・クライアント（１１０）に送信し、メディア制御シグナリングをメディア制御チャネル（１４２）を通してマルチメディア・クライアント（１１０）から受信する少なくとも１つのメディア制御インターフェイス（１２４）と、
    （ｃ）メディアストリームをメディア・チャネル（１４３）を通してマルチメディア・クライアント（１１０）に送信し、メディアストリームをメディア・チャネル（１４３）を通してマルチメディア・クライアント（１１０）から受信する少なくとも１つのメディア・インターフェイス（１２５）と、
    （ｄ）マルチメディア・クライアント（１１０）の１つから受信したメディアストリームを、複数のマルチメディア・クライアント向けの複数のメディアストリームに複写する複写ユニット（１２６）と、
    （ｅ）マルチメディア・クライアントがサポートするメディアタイプのセットを記憶する記憶領域（１２７）と、
    （ｆ）前記セッションシグナリングおよび前記メディア制御シグナリングを処理するプロセッサ・ロジック（１２８）と、
    を備えることを特徴とするアプリケーションサーバ（１２０）。
16. 前記マルチメディア・クライアント（１１０）の１つから受信したリクエスト・メディアタイプのセットと、前記マルチメディア・クライアントのいずれかがサポートするメディアタイプのセットとを比較し、前記１つのマルチメディア・クライアント（１１０）に、許容メディアタイプのセットを許可することを特徴とする請求項１５記載のアプリケーションサーバ（１２０）。
17. 前記マルチメディア・クライアント（１１０）の１つから受信したメディアストリーム中のメディアタイプの少なくとも１つを特定のマルチメディア・クライアントがサポートしていないときに、当該メディアタイプを終わらせることを特徴とする請求項１５記載のアプリケーションサーバ（１２０）。
18. 前記メディア制御インターフェイス（１２４）は、前記メディア・インターフェイス（１２５）に組み入れられていることを特徴とする請求項１５記載のアプリケーションサーバ（１２０）。
19. 前記シグナリングインターフェイス（１２３）が、ＳＩＰシグナリングをサポートすることを特徴とする請求項１５記載のアプリケーションサーバ（１２０）。

Images