JP5551786B2

JP5551786B2 - 会話期間中にマルチメディア呼出し音を再生する方法、サーバおよび端末デバイス

Info

Publication number: JP5551786B2
Application number: JP2012535618A
Authority: JP
Inventors: 文美 ▲ガオ▼; 国▲喬▼ ▲陳▼; 惠萍 ▲張▼; 健 ▲楊▼; ▲シュ▼男范; 雷王; 立李; 瑞▲ナン▼ ▲孫▼
Original assignee: ▲華▼▲為▼▲終▼端有限公司
Priority date: 2009-10-31
Filing date: 2010-10-29
Publication date: 2014-07-16
Anticipated expiration: 2030-10-29
Also published as: KR101407383B1; EP2479968A1; WO2011050744A1; CN101764802B; EP2479968A4; JP2013509755A; CN101764802A; EP2479968B1; KR20120066665A

Description

本発明は、マルチメディア呼出し音の分野に関し、特に、コール中にマルチメディア呼出し音を再生するための方法、サーバ、および、端末デバイスに関する。

本出願は、参照によりその内容全部を本明細書に組み込む、2009年10月31日に中国特許庁に出願した、中国特許出願第200910211356.9号、「METHOD, SERVER AND TERMINAL DEVICE FOR PLAYING MULTIMEDIA RING TONE DURING CALL」の優先権を主張するものである。

現在、マルチメディア呼出し音は主として、CAT(Customized Alerting Tone、カスタマイズされた警報音)、CRS(Customized Ringing Signal、カスタマイズされた呼出し信号)、およびCBT(Customized Background Tone、カスタマイズされた背景音)を含む。CATはまた、発呼者によってかけられた電話に被呼者が出る前に発呼者によって享受されるCATである、MRBT(Multimedia Ring Back Tone、マルチメディア呼出し背景音)とも称される。CRSはまた、発呼者によってかけられた電話に被呼者が出る前に被呼者によって享受されるCRSである、マルチメディア呼出し音とも称される。CBTはまた、発呼者および被呼者間のコール中に発呼者および被呼者の両方によって享受されるCBTである、マルチメディア背景音とも称される。マルチメディア呼出し音のコンテンツは、音楽、ビデオ、写真、テキスト、電子名刺、および、ユーザによってアップロードされたオーディオ/ビデオクリップさえも含む、さまざまなタイプのメディアコンテンツでもよい。

本発明の実装中、本発明者は、CRSサービスについて、先行技術では、発呼者が被呼者に電話をかけるときに被呼者がCRSサーバによって配信されるCRSを受信し、被呼者がその電話に出た後には、CRSサーバはCRSの再生を停止し、通常コール段階に入ることに着目した。CATサービスについて、先行技術では、発呼者が被呼者に電話をかけるときに発呼者はCATサーバによって配信されるCATを受信し、被呼者がその電話に出た後に、CATサーバはCATの再生を停止し、通常コール段階に入る。したがって、先行技術では、マルチメディア呼出し音をコール中に継続的に再生することはできない。

本発明の実施形態は、マルチメディア呼出し音をコール中にユーザのために継続的に再生することができないという先行技術の問題を解決するために、コール中にマルチメディア呼出し音を再生するための方法、サーバおよび端末デバイスを提供する。

本発明の実施形態の前述の目的は、以下の技術的解決法を介して実装される。

本発明の一実施形態は、コール中にマルチメディア呼出し音を再生する方法を提供し、この方法は、起呼端末または被呼端末によって送信される要求フラグを受信する段階と、その要求フラグにしたがって、コール中のマルチメディア呼出し音の継続的再生をトリガする段階とを含む。

さらに、本発明の一実施形態は、マルチメディア呼出し音アプリケーションサーバ(AS)を提供し、マルチメディア呼出し音ASは、起呼端末または被呼端末によって送信される要求フラグを受信するように構成された要求フラグ受信ユニットと、その要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするように構成された、マルチメディア呼出し音再生トリガユニットとを備える。

さらに、本発明の一実施形態は、マルチメディア呼出し音サーバを提供し、本マルチメディア呼出し音サーバは、マルチメディア呼出し音ASおよびマルチメディアリソース機能(MRF)のエンティティを含み、そのMRFのエンティティは、CRS/CATおよびコールメディアストリームのミキシングを実行するように構成された、ミキシングユニットと、CRSおよび/または混成CRSを再生するあるいはCATおよび/または混成CATを再生するように構成された、マルチメディア呼出し音再生ユニットとを備える。

さらに、本発明の一実施形態は、コール中にマルチメディア呼出し音を再生する方法を提供し、この方法は、マルチメディア呼出し音サーバにコール中に継続的にマルチメディア呼出し音を再生するように要求するために使用される要求フラグをマルチメディア呼出し音サーバに送信する段階を含む。

さらに、本発明の一実施形態は、端末デバイスを提供し、端末デバイスは、要求フラグをマルチメディア呼出し音サーバに送信するように構成された要求フラグ送信ユニットを備え、その要求フラグは、コール中に継続的にマルチメディア呼出し音を再生するようにマルチメディア呼出し音サーバに要求するために使用される。

別の態様では、コール中にマルチメディア呼出し音を再生する方法がさらに提供され、この方法は、コール中に継続的にマルチメディア呼出し音を再生するための、被呼者からオフフックメッセージを受信する段階と、メッセージを起呼端末および被呼端末に送信してセッションを更新する段階と、MRFにオーディオミキシング処理を実行するように指示する段階とを含む。

本発明の実施形態によるコール中にマルチメディア呼出し音を再生するための方法、サーバおよび端末デバイスは、マルチメディア呼出し音をコール中にユーザのために継続的に再生することができないという先行技術の問題を解決する。

本明細書で説明される以下の添付図面は、本願の一部を成すが、本発明を限定するものではなく、本発明のさらなる理解のために提供される。

本発明の一実施形態による方法の流れ図である。本発明の一実施形態によるネットワーク化の概略的構造図である。図2に示す一実施形態の対話流れ図である。図2に示す一実施形態の対話流れ図である。図2に示す一実施形態のもう1つの対話流れ図である。図2に示す一実施形態のもう1つの対話流れ図である。図2に示す一実施形態のもう1つの対話流れ図である。図2に示す一実施形態のもう1つの対話流れ図である。図2に示す一実施形態のもう1つの対話流れ図である。図2に示す一実施形態のもう1つの対話流れ図である。本発明のもう1つの実施形態によるネットワーク化の概略的構造図である。図7に示す一実施形態の対話流れ図である。本発明の一実施形態による呼出し音サーバの構成要素のブロック図である。本発明のもう1つの実施形態による方法の流れ図である。本発明の一実施形態による端末デバイスの構成要素のブロック図である。本発明の実施形態11の対話流れ図である。本発明の実施形態11の対話流れ図である。本発明の実施形態12による方法の概略図である。

本発明の目的、技術的解決法、および利点をより明らかにするために、本発明は、添付の図面および実施形態を参照して、本明細書で詳細に説明する。本発明の例示的な実施形態および実施形態の説明が本発明を説明するために使用されるが、本発明はそれらに限定されない。

(実施形態1)
本発明の実施形態は、コール中にマルチメディア呼出し音を再生する方法を提供し、本実施形態は添付の図面を参照して以下に詳細に説明する。

図1は、本発明の一実施形態による方法の流れ図である。図1を参照すると、本発明の本実施形態による方法は主に以下を含む:

ステップ101:起呼端末または被呼端末によって送信される要求フラグを受信する。

ステップ102:その要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガする。

本発明の本実施形態によるコール中にマルチメディア呼出し音を再生する方法は、コール中の起呼端末または被呼端末のためのマルチメディア呼出し音の継続的再生を実装することができる。

(実施形態2)
本発明の本実施形態はさらにコール中にマルチメディア呼出し音を再生する方法を提供し、本実施形態は添付の図面を参照して以下に詳細に説明する。

図1は、本発明の一実施形態による方法の流れ図である。図1を参照すると、本発明の方法は主に以下を含む:

本実施形態で、被呼端末によって送信される要求フラグは、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ドメイン内でオフフック応答メッセージ(200 OKメッセージ)によって運ばれうる、またはオフフック応答メッセージ後のINFOメッセージもしくはMESSAGEメッセージのヘッダフィールドもしくはメッセージ本体によって運ばれうる、あるいは、回線交換(CS)ドメイン内でUUIメッセージもしくはFACILITYメッセージによって運ばれうる、またはデュアルトーンマルチ周波数(DTMF)方式で運ばれうる。別法として、要求フラグは、被呼端末から帯域外方式またはオフライン方式で取得されうるが、本発明の実施形態はそれに限定されない。

本実施形態で、要求フラグは、CRSおよび起呼端末から被呼端末へのコールメディアストリームのミキシング動作を実行することをサーバに要求するCRSミキシングフラグでもよい。その場合、被呼端末のみがコール中にCRSを聴くことができる。

本実施形態で、要求フラグは、CATおよび被呼端末から起呼端末へのコールメディアストリームのミキシング動作を実行することをサーバに要求するCATミキシングフラグでもよい。その場合、起呼端末のみがコール中にCATを聴くことができる。

本実施形態で、要求フラグはまた、CRS/CATと起呼端末および被呼端末間のコールメディアストリームとにミキシング動作を実行することをサーバに要求するためのCBTミキシングフラグでもよい。その場合、起呼端末および被呼端末の両方がコール中にCRS/CATを聴くことができる。このとき、CRS/CATはCBTとして供される。

本実施形態で、要求フラグはまた、起呼端末または被呼端末がマルチメディア呼出し音をダウンロードし、コール中に局所的にマルチメディア呼出し音を再生するように、マルチメディア呼出し音リンクを配信するようにサーバに要求するためのマルチメディア呼出し音リンクダウンロードフラグでもよい。

本実施形態で、要求フラグはまた、発呼者または被呼者がマルチメディア呼出し音およびコールメディアストリームのミキシングを実行し、混成マルチメディア呼出し音を局所的に再生するように、マルチメディア呼出し音の再生を停止しないようにサーバ側に要求するための端末ミックス機能フラグでもよい。その場合、起呼端末または被呼端末がミキシング機能をもつ必要がある。

ステップ102:要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガする。

本実施形態で、受信要求フラグがCRSミキシングフラグである場合、要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするステップは、以下のように説明される。

CRSミキシングフラグを運ぶ指示メッセージがMRFエンティティに送信されて、MRFエンティティにCRSおよび起呼端末から被呼端末へのコールメディアストリームのオーディオミキシング/ミキシングを実行するように命令する。

本実施形態で、受信要求フラグがCATミキシングフラグである場合、要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするステップは、以下のように説明される。

CATミキシングフラグを運ぶ指示メッセージがMRFエンティティに送信されて、MRFエンティティにCATおよび被呼端末から起呼端末へのコールメディアストリームのオーディオミキシング/ミキシングを実行するように命令する。

本実施形態で、受信された要求フラグがCBTミキシングフラグである場合、要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするステップは、以下のように説明される。

CBTミキシングフラグを運ぶ指示メッセージがMRFエンティティに送信されて、MRFエンティティにCRS/CATと起呼端末および被呼端末間のコールメディアストリームとのオーディオミキシング/ミキシングを実行するように命令する。

本実施形態によれば、指示メッセージがCRS/CATと発呼者および被呼者間のコールメディアストリームとのオーディオミキシング/ミキシングを実行するように命令する場合、それは、CRSまたはCATがCBTに変換されることになることを意味する。したがって、本実施形態の本方法はさらに、起呼端末および被呼端末とCBTを交渉するステップを含む必要がある。

CBT要求が起呼端末および被呼端末に送信されてCBTセッションを交渉する。

CBT要求に応答する起呼端末および被呼端末の応答メッセージが受信される。

本実施形態で、CBT要求は、re-INVITEメッセージを介して転送されうる、またはREFERメッセージを介して転送されうるが、本実施形態はそれに限定されない。

本実施形態の本方法によれば、起呼端末および被呼端末間のコール中、起呼端末、または被呼端末、あるいは起呼端末および被呼端末の両方は、継続的にマルチメディア呼出し音を聴くことができる。マルチメディア呼出し音は、サーバ側がCRS/CATおよびコールメディアストリームのミキシングを実行した後に、サーバ側によって再生され、したがって、起呼端末または被呼端末がオンフックになった後、本実施形態の本方法はさらに以下のステップを含む。

オンフックメッセージが受信された後、停止メッセージがMRFエンティティに送信されて、オーディオミキシング/ミキシング動作を停止するように、およびマルチメディア呼出し音の再生を停止するようにMRFエンティティに命令する。

MRFエンティティによって返された停止肯定応答メッセージが受信されて、オーディオミキシング/ミキシング動作が停止され、マルチメディア呼出し音の再生が停止されたことを確認する。

本実施形態で、IMSドメインにおいて、オンフックメッセージはBYEメッセージでもよく、CSドメインにおいて、オンフックメッセージは切断メッセージでもよい。

本実施形態で、受信された要求フラグがマルチメディア呼出し音リンクダウンロードフラグである場合、要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするステップは以下のように説明される。

マルチメディア呼出し音リンクダウンロードフラグを運ぶ指示メッセージがMRFエンティティに送信されて、マルチメディア呼出し音リンクを送信するようにMRFエンティティに命令する。

MRFエンティティによって返され、マルチメディア呼出し音リンクを含み、指示メッセージに応答する、応答メッセージが受信される。

本実施形態によれば、オフフック応答メッセージに応答する起呼端末の肯定応答メッセージが受信された後、マルチメディア呼出し音リンクを運ぶ肯定応答メッセージが要求端末に送信され、要求端末がマルチメディア呼出し音リンクを取得し、マルチメディア呼出し音をダウンロードした後に、マルチメディア呼出し音が局所的に再生されうる。

本実施形態で、受信された要求フラグが端末ミックス機能フラグである場合、要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするステップは、以下のように説明される。

オフフック応答メッセージが受信された後、マルチメディア呼出し音が継続的に再生される。

本実施形態の本方法によれば、サーバ側はマルチメディア呼出し音の送信を停止しないため、要求端末はマルチメディア呼出し音およびコールメディアストリームのオーディオミキシング/ミキシングを実行し、混成マルチメディア呼出し音を局所的に再生することができる。したがって、起呼端末および被呼端末がオンフックになった後、本実施形態の本方法はさらに以下のステップを含む。

オンフックメッセージが受信された後、停止メッセージがMRFエンティティに送信されてマルチメディア呼出し音の再生を停止するようにMRFエンティティに命令する。

MRFエンティティによって返された停止肯定応答メッセージが受信されて、マルチメディア呼出し音の再生が停止されたことを確認する。

本実施形態で、ユーザのために再生されるマルチメディア呼出し音ファイルが、写真、テキスト、電子名刺などのファイルである場合、マルチメディア呼出し音サーバが対応する要求フラグを受信し、200 OKメッセージを受信した後は、マルチメディア呼出し音サーバはオーディオミキシング/ミキシング動作を実行せず、代わりに、マルチメディア呼出し音サーバのみがマルチメディア呼出し音ファイルの再生を続ける。

本実施形態の本方法を介して、起呼端末、または被呼端末、あるいは起呼端末および被呼端末の両方は、コール中に、マルチメディア呼出し音を継続的に聴くことができ、それによって、コール中にマルチメディア呼出し音をユーザのために継続的に再生することができないという先行技術の問題、ならびに、コール中にCRSまたはCATをCBTに変換する問題を解決する。

本実施形態の本方法は、回線交換ドメイン(CSドメイン)内のコールプロセスに適用可能であるだけではなく、IMSドメイン(IPマルチメディアサブシステム)内のコールプロセスにも適用可能であり、IMSドメインにおける初期セッション方式、マルチセッション方式、ゲートウェイ方式で、ならびに、CSドメインにおけるブリッジ方式および非ブリッジ方式で、コール中にCRS(またはCAT)の継続的再生を実装する。以下の異なる実施形態が説明のために挙げられる。

(実施形態3)
本実施形態における一方法は、IMSドメインにおける初期セッション方式に適用可能である。サーバ側は、CRSおよびコールメディアストリームのミキシングを実行して被呼者への単方向「CRS+コール」を実装する。

本実施形態で、被呼端末のユーザがオフフックであるとき、サーバのミキシング要求フラグは、被呼者によって送信される200 OKメッセージで運ばれる。本実施形態で、フラグはCRSミキシングフラグである。CRS-ASがそのフラグを受信した後、CRS-ASは、対応する動作をトリガする、即ち、CRS-ASがCRSおよびコールメディアストリームにミキシング動作を実行するようにMRFエンティティMRFに命令し、混成メディアストリームを被呼端末に送信する。

本実施形態で、要求端末は被呼者であり、起呼端末Aのユーザは被呼端末BのユーザのためにCRSサービスをカスタマイズすると仮定される。AがBをコールするとき、CRS-ASは、BのためにCRSを再生するようにMRFに命令する。Bがそのコールに応答するとき、ユーザ機器(UE)Bによって送信される200 OKメッセージは、サーバのためのミキシング要求フラグを運び、そのフラグは起呼端末上の起呼端末のユーザが事前設定することができる。フラグをパーズした後、CRS-ASはCRSおよびAからBへのコールのミキシング処理を実行するようにMRFに命令する。端末Bのユーザは、端末Aのユーザとのコール中にCRSマルチメディアコンテンツを継続的に楽しむことができる。CRSおよびコールメディアストリームの両方は、オーディオまたはビデオの形式でもよい。CRSがオーディオである場合、オーディオミキシングはCRSおよびコールストリームに直接実行することができ、CRSがビデオである場合、ビデオミキシングをCRSビデオおよびコールビデオストリームに実行し、次にCRSビデオおよびそのコールビデオストリームを別々のスクリーンに表示することができる。

図2は、図2に示すように、実施形態のネットワーク化の構造図である。

UE(user equipment)は、ユーザ機器である。本実施形態で、UE-Aは起呼端末であり、UE-Bは被呼端末である。

ノードB(Node B)は、広帯域符号分割多元接続(WCDMA)システムの基地局であり、即ち、主にUuインターフェース物理レイヤプロトコルの処理を達成する、無線送受信機である。

RNC(Radio Network Controller)は、無線ネットワーク制御装置であり、UTRAN(Universal Terrestrial Radio Access Network、ユニバーサル地上波無線アクセスネットワーク)の無線リソースを制御するように構成される。

SGSN(Serving GPRS Support Node)は、サービング汎用パケット無線サービス(GPRS)サポートノードであり、WCDMAコアネットワークのパケット交換(PS)ドメイン内の機能的ノードであり、PSドメインのルーティングフォワード、モビリティ管理、セッション管理、認証および暗号化などの機能を主に提供する。

P-CSCF(Proxy Call Session Control Function)は、プロキシコールセッション制御機能である。P-CSCFは、IMSネットワークにおけるユーザの第1の接触点であり、主に要求認証と応答処理および転送とに関与する。

S-CSCF(Serving Call Session Control Function)は、サービングコールセッション制御機能である。S-CSCFは、IMSネットワークでコア制御状況にあり、IMSマルチプロセス制御において重要な役割を果たす。S-CSCFは、ユーザのプロセスの状態の記録および制御と、セッションルーティング機能の実行と、規則にしたがって付加価値サービスのトリガおよびサービス制御を実行するためのアプリケーションサービス機能および課金機能との継続的対話とに関与する。

HSS(Home Subscriber Server)は、ホーム加入者サーバである。HSSは、ユーザおよびサービスに関連するデータを保存するデータベースであり、アップグレードされたホームロケーションレジスタ(HLR)である。HSSは、ユーザ識別、登録情報、アクセスパラメータ、およびサービストリガ情報を拡張可能なマーク付け言語(XML)の形式で記録する。

CRS-AS(Customized Ringing Signal Application Server)は、カスタマイズされた呼出し信号アプリケーションサーバである。CRS-ASは、IMSネットワークにおいてユーザのためにIPマルチメディア(IM)付加価値サービスを提供するサーバである。CRS-ASは、ユーザのホームネットワーク内に置くことができ、第三者によって提供されうる。CRS-ASは主に、CRSサービスを提供し、MRFを制御してメディアリソースを再生するように構成される。

MRF(Multimedia Resource Function)は、マルチメディアリソース機能エンティティである。MRFは、制御部分(MRFC)およびユーザプレーンの処理部分(MRFP)を含み、マルチメディアリソース再生、ビデオ会議およびユーザ広告などのベアラ関連サービスにサポートを提供し、データメディアストリームのミキシング、メディアストリームの配信、ベアラ符号の変換、および課金情報の送信を遂行することができる。

CRS-ASおよびMRFの組合せは、CRSサーバと称されうる。同様に、CAT-ASおよびMRFの組合せはCATサーバと称することができ、CBT-ASおよびMRFの組合せはCBTサーバと称することができる。CRS-AS、CAT-AS、CBT-ASおよびMRFの組合せはマルチメディア呼出し音サーバと称することができる。

図3Aおよび3Bは、本実施形態のコールプロセスの概略図である。図3Aおよび3Bに示すように。

ステップ301からステップ302:起呼端末UE-Aが、被呼端末UE-Bとのコールを確立するために、正規セッション(Session)セッション記述プロトコル(SDP)オファ(O1)を運ぶINVITE要求を送信する。INVITE要求は、先ずS-CSCFに到達し、S-CSCFの初期フィルタ基準(iFC)にしたがってCRS-ASに経路指定される。

ステップ303からステップ304:CRS-ASが、UE-AはUE-BについてCRSサービスに既に加入していることを確認し、MRFにSDPなしでINVITE要求を送信する。MRFが、応答として200 OKメッセージを返す。200 OKメッセージは、初期セッションSDPオファ(CRS-O)を運ぶ。その目的は、UE-BおよびMRFの間でCRSメディアストリームを確立することである。

ステップ305からステップ307:CRS-ASがINVITE要求を生成し、INVITE要求がS-CSCFおよびP-CSCFを介してUE-Bに到達する。INVITE要求は、2つのSDP、即ち、正規セッションSDPオファ(O1)および初期セッションSDPオファ(CRS-O)を含む。さらに、INVITEの要求ヘッダフィールドは、初期セッションオプションラベルを含む。

ステップ308からステップ3010:被呼端末UE-Bが、INVITE要求内の初期セッションSDPオファ(CRS-O)に応答し、高信頼183一時応答を返す。本183は、初期セッションSDP返答(CRS-A)を運び、183の要求ヘッダフィールドは、100relオプションラベルを含む。

ステップ3011:CRS-ASが183を受信した後、CRS-ASは肯定応答メッセージACKをMRFに送信し、そのACKは初期セッションSDP返答(CRS-A)を運ぶ。

ステップ3012からステップ3013:CRS-ASが183をS-CSCFに送信し、S-CSCFは183を起呼端末UE-Aに転送する。

ステップ3014からステップ3018:UE-Aが、183に応答して高信頼応答PRACKを返し、PRACKがS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。

ステップ3019からステップ3021:UE-Bが、PRACKに応答して肯定応答メッセージ200 OKを返し、200 OKはP-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ3022からステップ3023:CRS-ASがINFOメッセージをMRFに送信してMRFにUE-BのためにCRSの再生を開始するように命令する。MRFが肯定応答として200 OKメッセージを返し、CRSの再生を開始する。この時点で、被呼者Bは、発呼者AによってカスタマイズされたCRSをUE-Bから聴く/見ることになる。

ステップ3024からステップ3028:UE-Bが180 CRSメッセージを返し、180 CRSメッセージがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-Aに到達する。

ステップ3029からステップ3031:被呼者Bがその電話に出て、UE-Bが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを送信する。本実施形態の本方法によれば、200 OKメッセージは、同時にオーディオミキシング/ミキシング要求(ミキシング要求)フラグ、即ちCRSミキシングフラグ、も運び、本フラグは、セッション開始プロトコル(SIP)ヘッダフィールド、SDP、またはXMLファイルを介して運ばれうる。XML運搬方式では、SIPヘッダフィールド内のコンテンツタイプを複数パート/混成タイプに設定することができ、そうするとXMLファイルはSDPメッセージ本体の後に運ばれうる。200 OKメッセージは、P-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ3032からステップ3033:本実施形態の本方法によれば、CRS-ASがミキシング要求フラグを運ぶ200 OKメッセージを受信した後、CRS-ASはINFOメッセージをMRFに送信し、そのINFOは、ミックスユニットを起動してCRSおよびコールメディアストリームのオーディオミキシング/ミキシングを実行する準備をするようにMRFに命令するために、SDPまたはヘッダフィールドのフィールドを介してミキシング要求フラグを運ぶ。MRFが、INFOに応答して応答メッセージ200 OKを返す。

ステップ3034からステップ3035:CRS-ASが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを転送し、200 OKメッセージがS-CSCFを介してUE-Aに到達する。

ステップ3036からステップ3040:UE-Aが200 OKメッセージに応答して肯定応答メッセージACKを返し、肯定応答メッセージACKがS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。この時点で、正規コールがUE-AおよびUE-Bの間に確立される。本実施形態の本方法によれば、MRFは、ミキサ(オーディオ/ビデオミキサ)の役割を果たし、発呼者および被呼者の間のコールパスで固定される。ミックス動作は、発呼ユーザおよびCRSのオーディオ/ビデオに実行され、発呼ユーザおよびCRSのオーディオ/ビデオがメディアストリームの1つのパスに結合され、被呼端末UE-Bに送信される。MRFは、UE-BからUE-Aへのオーディオ/ビデオメディアストリームにミックス動作を実行しない。

ステップ3041からステップ3052:被呼者Bはオンフックであり、UE-BがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-AにBYEメッセージを送信する。本実施形態の本方法によれば、CRS-ASがBYEメッセージを受信した後、CRS-ASがBYEメッセージをMRFに送信して、ミックス動作を停止し、CRSの再生を停止するようにMRFに命令する。UE-Aが、200 OKメッセージをUE-Bに返す。コールが終了する。

本実施形態のステップ3029からステップ3031では、200 OKによって運ばれるのとは別に、サーバのためのミキシング要求フラグ(CRSミキシングフラグ)もまた、200 OKメッセージの後にINFOまたはMESSAGEなどのメッセージによって運ばれうる。本実施形態はそれに限定されない。加えて、オフフックであるときに200 OKメッセージを介してミキシング要求フラグを運ぶのとは別に、被呼者はまた、帯域外方式(ショートメッセージなど)でまたはオフライン方式(ウェブなど)でミキシング要求を実装することができる。

本実施形態で、ミキシング(ミックス)動作はサーバ側によって実行されるため、先行技術でのネットワークエンティティは、その機能をサポートすることができる。加えて、本実施形態は端末側への要求をもたず、通常の端末がコール中のCRSの正規受信を実装することができる。

(実施形態4)
本実施形態における一方法は、IMSドメインでの初期セッション方法に適用可能である。サーバ側は、CRSおよびコールメディアストリームにミキシングを実行して、発呼者および被呼者への双方向の「CRS+コール」を実装する。

本実施形態で、被呼者のユーザがオフフックのとき、被呼端末によって送信される200 OKメッセージがサーバのためのミキシング要求フラグを運ぶ。本実施形態で、フラグは、CBTミキシングフラグである。CRS-ASが、フラグを受信した後に、対応する動作をトリガする、即ち、CRS-ASはCBTのミキシング動作を実行するようにMRFに命令する。CRS-ASが、CBTセッションSDPオファを運ぶre-INVITE要求を起呼端末および被呼端末に送信する。起呼端末および被呼端末が互いに応答した後に、MRFはCBT再生モードに入る、即ち、起呼端末および被呼端末間のコール中にCBTを再生する。

本実施形態で、要求端末は、被呼端末である。被呼端末Bのユーザがオフフックであるとき、CRS-ASはMRFにCRSモードをCBTモードに変換する動作を実行するように命令するものと仮定する。このようにして、起呼端末のユーザおよび被呼端末のユーザの間のコール中に、両者は、MRFによって再生されるCBT(オーディオまたはビデオなどのマルチメディアコンテンツ)を楽しむことができる。

本実施形態のネットワーク構造および機能は、実施形態3と同じであり、本明細書において再度詳述はしない。

図4Aおよび4Bは、本実施形態のコールプロセスの概略図である。図4Aおよび4Bに示すように。

ステップ401からステップ402:起呼端末UE-Aが、被呼端末UE-Bとのコールを確立するために、正規セッションSDPオファ(O1)を運ぶINVITE要求を送信する。そのINVITE要求は、先ずS-CSCFに到達し、S-CSCF内の初期フィルタ基準iFCにしたがってCRS-ASに経路指定される。

ステップ403からステップ404:CRS-ASが、UE-Aは既にUE-BについてCRSサービスに加入していることを確認し、MRFにSDPなしでINVITE要求を送信する。MRFが、応答として200 OKメッセージを返す。200 OKメッセージが、初期セッション(Early-session)SDPオファ(CRS-O)を運ぶ。本目的は、UE-BおよびMRFの間にCRSメディアストリームを確立することである。

ステップ405からステップ407:CRS-ASがINVITE要求を生成し、INVITE要求がS-CSCFおよびP-CSCFを介してUE-Bに到達する。INVITE要求は、2つのSDP、即ち、正規セッションSDPオファ(O1)および初期セッションSDPオファ(CRS-O)を含む。さらに、INVITEの要求ヘッダフィールドは、初期セッションオプションラベルを含む。

ステップ408からステップ4010:被呼端末UE-Bは、INVITE要求内の初期セッションSDPオファ(CRS-O)に応答し、高信頼183一時応答を返す。183は初期セッションSDP返答(CRS-A)を運び、183の要求ヘッダフィールドは100relオプションラベルを含む。

ステップ4011:183を受信した後、CRS-ASが肯定応答メッセージACKをMRFに送信し、そのACKが初期セッションSDP返答(CRS-A)を運ぶ。

ステップ4012からステップ4013:CRS-ASが183をS-CSCFに送信し、S-CSCFが183を起呼端末UE-Aに転送する。

ステップ4014からステップ4018:UE-Aが183に応答して高信頼応答PRACKを返し、PRACKがS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。

ステップ4019からステップ4021:UE-BがPRACKに応答して肯定応答メッセージ200 OKを返し、200 OKがP-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ4022からステップ4023:CRS-ASがINFOメッセージをMRFに送信して、UE-BのためのCRSの再生を開始するようにMRFに命令する。MRFが、肯定応答として200 OKメッセージを返し、CRSの再生を開始する。この時点で、被呼者Bは、発呼者AによってカスタマイズされたCRSをUE-Bから聴く/見ることになる。

ステップ4024からステップ4028:UE-Bが180 CRSメッセージを返し、l80 CRSメッセージがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-Aに到達する。

ステップ4029からステップ4031:被呼者Bがその電話に出て、UE-Bが、正規セッションSDP返答(AI)を運ぶ200 OKメッセージを送信する。本実施形態の本方法によれば、200 OKメッセージはまた、同時にオーディオミキシング/ミキシング要求(ミキシング要求)フラグ、即ち第2のSDP、ヘッダフィールドのフィールドまたはXMLファイルを介して運ばれうるCBTミキシングフラグ、を運び、P-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ4032からステップ4033:本実施形態の本方法によれば、CRS-ASがミキシング要求フラグを運ぶ200 OKを受信した後に、CRS-ASがINFOメッセージをMRFに送信し、INFOは、ミックスユニットを起動してCRSおよびコールメディアストリームのオーディオミキシング/ミキシングを実行する準備をするようにMRFに命令するために、SDPまたはヘッダフィールドのフィールドを介してミキシング要求フラグを運ぶ。MRFがINFOメッセージに応答して応答メッセージ200 OKを返す。

ステップ4034からステップ4035:CRS-ASが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを転送し、200 OKメッセージがS-CSCFを介してUE-Aに到達する。

ステップ4036からステップ4040:UE-Aが200 OKメッセージに応答して肯定応答メッセージACKを返し、ACKがS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。

ステップ4041からステップ4043:本実施形態の本方法によれば、CRS-ASが、CBTセッションを再交渉するために、CBTセッションSDPオファ(O2)を運ぶre-INVITE要求をUE-Bに送信する。

ステップ4044からステップ4045:本実施形態の本方法によれば、CRS-ASが、CBTセッションを再交渉するために、CBTセッションSDPオファ(O2)を運ぶre-INVITE要求をUE-Aに送信する。

ステップ4046からステップ4048:本実施形態の本方法によれば、UE-Bが、re-INVITEに応答して、CBTセッションSDP返答(A2)を運ぶ200 OKメッセージをCRS-ASに返す。

ステップ4049からステップ4050:本実施形態の本方法によれば、UE-Aが、re-INVITE要求に応答して、CBTセッションSDP返答(A2)を運ぶ応答200 OKメッセージをCRS-ASに返す。

この時点で、正規コールがUE-AおよびUE-Bの間に確立される。MRFは、ミキサ(オーディオ/ビデオミキサ)の役割を果たし、発呼者および被呼者間のコールパスに固定される。ミックス動作が発呼/被呼者およびCRSのオーディオ/ビデオに実行され、混成オーディオ/ビデオおよびCRSが、それぞれ、発呼者および被呼者に送信される。この時点で、CRSはCBTとも称されうる。

ステップ4051からステップ4062:被呼者Bがオンフックであり、UE-BがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-AにBYEメッセージを送信する。本発明の本方法によれば、CRS-ASがBYEメッセージを受信した後、CRS-ASはBYEメッセージをMRFに送信して、ミキシング動作を停止し、CBTの再生を停止するようにMRFに命令する。UE-Aが、200 OKメッセージをUE-Bに返す。コールが終了する。

本実施形態のステップ4041からステップ4054で、re-INVITEの方法はまた、REFERの方法と置き換えることができる。即ち、CRS-ASが起呼端末および被呼端末にREFER要求を送信して、起呼端末および被呼端末にCBTモードに加わるように勧誘し、Refer-toフィールドがCBTモードでURI(Uniform Resource Identifier)を運ぶ。起呼端末および被呼端末が、MRFにその端末がその要求を受信したことを通知するために、受諾応答を返し、NOTIFYメッセージを送信する。MRFが200 OKメッセージを返す。このようにして、起呼端末および被呼端末がCBTモードに入る。

本実施形態では、ミキシングはサーバ側によって実行され、したがって、本実施形態は端末側に要求をもたない。加えて、発呼者および被呼者の両方がマルチメディア背景コンテンツを楽しむことができるように、コール中に、CRSモードがCBTモードに変換される。

(実施形態5)
本実施形態における一方法は、IMSドメインにおける初期セッション方式に適用可能である。端末が、CRSおよびコールメディアストリームのオーディオミキシング/ミキシングを実行して被呼者への単方向「CRS+コール」を実装する。

本実施形態で、被呼端末のユーザがオフフックになった後、被呼端末が200 OKメッセージ内で端末ミックス機能フラグを運ぶ。CRS-ASがフラグを受信した後、CRS-ASはBYEメッセージをMRFに送信しない。MRFが、起呼端末および被呼端末間のコール中にCRSの再生を続ける。被呼端末が、同時に2つのパスのメディアストリームを受信し、被呼端末のローカルミキシングユニットを使用してミキシング動作を実行する。

本実施形態で、要求端末は被呼端末である。被呼端末Bは2つのパスのメディアストリームにオーディオミキシング/ミキシングを実行する機能をもち、さらに、コール中にCRSメディアストリームを受信し、オーディオミキシング/ミキシングがその2つのパスのメディアストリームに実行された後に、被呼端末のユーザにその2つのパスのメディアストリームを表示(または再生)することができるものと仮定する。

本実施形態のそのネットワーク構造および機能は、実施形態3と同じであり、本明細書で再び詳述はしない。

図5Aおよび5Bは、本実施形態のコールプロセスの概略図である。図5Aおよび5Bに示すように、

ステップ501からステップ502:起呼端末UE-Aが、被呼端末UE-Bとのコールを確立するために、セッション(Session)SDPオファ(O1)を運ぶINVITE要求を送信する。そのINVITE要求は、先ずS-CSCFに到達し、S-CSCF内のiFCにしたがってCRS-ASに経路指定される。

ステップ503からステップ504:CRS-ASが、UE-AはUE-BのためのCRSサービスに既に加入していることを確認し、CRS-ASがMRFにSDPなしでINVITE要求を送信する。MRFが、応答として200 OKメッセージを返す。200 OKメッセージは、初期セッションSDPオファ(CRS-O)を運ぶ。その目的は、UE-BおよびMRFの間にCRSメディアストリームを確立することである。

ステップ505からステップ507:CRS-ASがINVITE要求を生成し、INVITE要求がS-CSCFおよびP-CSCFを介してUE-Bに到達する。INVITE要求は、2つのSDP、即ち、正規セッションSDPオファ(O1)および初期セッションSDPオファ(CRS-O)を含む。さらに、INVITEの要求ヘッダフィールドは初期セッションオプションラベルを含む。

ステップ508からステップ5010:被呼端末UE-BがINVITE要求内の初期セッションSDPオファ(CRS-O)に応答し、高信頼183一時応答を返す。183は初期セッションSDP返答(CRS-A)を運び、183の要求ヘッダフィールドは100relオプションラベルを含む。

ステップ5011:CRS-ASが183を受信した後、CRS-ASが肯定応答メッセージACKをMRFに送信し、そのACKが初期セッションSDP返答(CRS-A)を運ぶ。

ステップ5012からステップ5013:CRS-ASが183をS-CSCFに送信し、S-CSCFが183を起呼端末UE-Aに転送する。

ステップ5014からステップ5018:UE-Aが183に応答して高信頼応答PRACKを返し、PRACKがS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。

ステップ5019からステップ5021:UE-BがPRACKに応答して肯定応答メッセージ200 OKを返し、200 OKがP-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ5022からステップ5023:CRS-ASがINFOメッセージをMRFに送信して、MRFにUE-BのためのCRSの再生を開始するように命令する。MRFが、肯定応答として200 OKメッセージを返し、CRSの再生を開始する。この時点で、被呼者Bは、発呼者AによってカスタマイズされたCRSをUE-Bから聴く/見ることになる。

ステップ5024からステップ5028:UE-Bが180 CRSメッセージを返し、180 CRSメッセージがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-Aに到達する。

ステップ5029からステップ5031:被呼者Bがその電話に応答して、UE-Bが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを送信する。本実施形態の本方法によれば、200 OKメッセージはまた、端末がオーディオミキシング/ミキシング機能をもつことを指示するために、端末ミックス機能フラグも同時に運び、そのフラグは第2のSDP、ヘッダフィールドまたはXMLファイルのフィールドによって運ぶことができ、P-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ5032からステップ5033:CRS-ASが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを転送し、その200 OKメッセージはS-CSCFを介してUE-Aに到達する。

ステップ5034からステップ5038:UE-Aが200 OKメッセージに応答して肯定応答メッセージACKを返し、その肯定応答メッセージACKはS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。

この時点で、UE-AおよびUE-B間の正規コールが確立され、発呼者および被呼者の間のオーディオ/ビデオ通話はリアルタイムプロトコル(RTP)ストリームメディアを介して伝送される。同時に、MRFはUE-BのためにCRSを継続的に再生する。UE-Bは、受信された2つのパスのメディアストリームにミキシング動作を実行し、その2つのパスのメディアストリームを1つのパスのメディアストリームに結合し、その結合されたメディアストリームを再生する。

ステップ5039からステップ5050:被呼者Bはオンフックであり、UE-BがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-AにBYEメッセージを送信する。本実施形態の本方法によれば、CRS-ASがBYEメッセージを受信した後、CRS-ASがBYEメッセージをMRFに送信して、CRSの再生を停止するようにMRFに命令する。MRFが、BYEメッセージに応答して200 OKメッセージを返す。UE-Aが、200 OKメッセージをUE-Bに返す。コールが終了する。

本実施形態で、ミキシングが被呼端末によって実行され、したがって、本実施形態はサーバに要求をもたず、サーバの処理手順を減らすことができ、サーバの負荷を減らすことができる。しかし、端末への要求は高く、特別なミキシングモジュールが従来の端末に追加されなければならない。

(実施形態6)
本実施形態の一方法は、IMSドメインにおける初期セッション方式に適用可能である。端末が帯域外方式でCRSをダウンロードして、コール中の被呼者のための局所的再生を実装する。

本実施形態で、被呼端末のユーザがオフフックであるとき、被呼端末が、ダウンロードおよび局所的再生を実行するために、200 OKメッセージ内でCRSダウンロードフラグを運び、サーバにCRS URIリンクを配信するように要求する。CRS-ASがフラグを受信した後、CRS-ASが、CRS URIを被呼端末に配信し、現在のCRSの再生を停止するようにMRFに命令する。被呼端末がCRS URIを受信した後、被呼端末がハイパテキスト転送プロトコル(HTTP)を介して第三者のウェブサーバからCRSをダウンロードし、コール中に局所的にそのCRSを再生する。

本実施形態で、要求端末は被呼端末である。被呼端末Bのユーザは、CRSをダウンロードし、コール中に局所的にCRSを再生することを期待するものと仮定する。

図6Aおよび6Bは、本実施形態のコールプロセスの概略図である。図6Aおよび6Bに示すように。

ステップ601からステップ602:起呼端末UE-Aが、被呼端末UE-Bとのコールを確立するために、正規セッションSDPオファ(O1)を運ぶINVITE要求を送信する。INVITE要求は先ずS-CSCFに到達し、S-CSCF内のiFCにしたがってCRS-ASに経路指定される。

ステップ603からステップ604:CRS-ASがUE-Aは既にUE-BについてのCRSサービスに加入していることを確認し、CRS-ASがMRFにSDPなしでINVITE要求を送信する。MRFが、応答として200 OKメッセージを返す。200 OKメッセージが、初期セッション(Early-session)SDPオファ(CRS-O)を運ぶ。その目的は、UE-BおよびMRFの間にCRSメディアストリームを確立することである。

ステップ605からステップ507:CRS-ASがINVITE要求を生成し、INVITE要求がS-CSCFおよびP-CSCFを介してUE-Bに到達する。INVITE要求は2つのSDP、即ち、正規セッションSDPオファ(O1)および初期セッションSDPオファ(CRS-O)を含む。さらに、INVITEの要求ヘッダフィールドは初期セッションオプションラベルを含む。

ステップ608からステップ6010:被呼端末UE-BがINVITE要求内の初期セッションSDPオファ(CRS-O)に応答し、高信頼183一時応答を返す。183は初期セッションSDP返答(CRS-A)を運び、183の要求ヘッダフィールドは100relオプションラベルを含む。

ステップ6011:183を受信した後、CRS-ASがMRFに肯定応答メッセージACKを送信し、ACKが初期セッションSDP返答(CRS-A)を運ぶ。

ステップ6012からステップ6013:CRS-ASが183をS-CSCFに送信し、S-CSCFが183を起呼端末UE-Aに転送する。

ステップ6014からステップ6018:UE-Aが183に応答して高信頼応答PRACKを返し、PRACKがS-CSCF、CRS-AS、S-CSCFおよびP-CSCFを介してUE-Bに到達する。

ステップ6019からステップ6021:UE-BがPRACKに応答して肯定応答メッセージ200 OKを返し、200 OKがP-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ6022からステップ6023:CRS-ASがINFOメッセージをMRFに送信し、MRFにUE-BのためのCRSの再生を開始するように命令する。MRFが、肯定応答として200 OKメッセージを返し、CRSの再生を開始する。この時点で、被呼者Bは、発呼者AによってカスタマイズされたCRSをUE-Bから聴く/見ることになる。

ステップ6024からステップ6028:UE-Bが180 CRSメッセージを返し、180 CRSメッセージがP-CSCF、S-CSCF、CRS-ASおよびS-CSCFを介してUE-Aに到達する。

ステップ6029からステップ6031:被呼者Bがそのコールに応答して、UE-Bが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを送信する。本実施形態の本方法によれば、200 OKメッセージはまた、同時にCRS URI要求フラグを運び、そのフラグは第2のSDP、Alert-Info/Call-InfoヘッダフィールドまたはXMLファイルを介して運搬可能であり、P-CSCFおよびS-CSCFを介してCRS-ASに到達する。

ステップ6032からステップ6033:CRS-ASが200 OKを受信した後、CRS-ASがBYEメッセージをMRFに送信して、CRSの再生を停止するようにMRFに命令する。本実施形態の本方法によれば、BYEメッセージは、CRSのHTTP URIを送信するようにMRFに命令するために、SDPを介してCRS URI要求フラグを運ぶ。MRFが、BYEメッセージに応答して200 OKメッセージを返す。本実施形態の本方法によれば、200 OKは、SDPまたはヘッダフィールドのフィールドを介してCRSのHTTP URIを運ぶ。

ステップ6034からステップ6035:CRS-ASが正規セッションSDP返答(Al)を運ぶ200 OKメッセージを転送し、200 OKメッセージがS-CSCFを介してUE-Aに到達する。

ステップ6036からステップ6040:UE-Aが200 OKメッセージに応答して肯定応答メッセージACKを返し、ACKがS-CSCFを介してCRS-ASに到達する。本実施形態の本方法によれば、CRS-ASは、SDPまたはACKメッセージ内のヘッダフィールドのフィールドにCRSのHTTP URIを追加し、そのACKメッセージをS-CSCFおよびP-CSCFを介して被呼端末UE-Bに送信する。

この時点で、UE-Bが、CRSの受信されたHTTP URIを介して第三者のウェブサーバからCRSをダウンロードし、局所的再生を実行する。

この時点で、UE-AおよびUE-B間の正規コールが確立され、発呼者および被呼者間のオーディオ/ビデオ通話がRTPストリームメディアを介して伝送される。

ステップ6041からステップ6050:被呼者Bはオンフックであり、UE-BがBYEメッセージをUE-Aに送信する。UE-Aが、200 OKメッセージをUE-Bに返す。コールが終了する。

本実施形態で、CRSサーバおよび端末の両方でミキシング要求はもたらされず、本実施形態は最も経済的解決法である。しかし、CRSがウェブサーバからダウンロードされる必要があり、遅延がもたらされることがあり、オーディオCRSのみが再生されうる。

(実施形態7)
本実施形態における一方法は、CSドメインにおいてブリッジ方式に適用可能である。サーバ側が、CRSおよびコールメディアストリームのミキシングを実行して単方向「CRS+コール」を被呼者に実装する。

本実施形態で、被呼端末のユーザがオフフックであるとき、被呼端末は、CONNECTメッセージにおいてミキシング要求フラグを運ぶ。CRSサーバは、CRSおよび起呼端末から被呼端末へのコールメディアストリームのミキシングを実行して、被呼端末のユーザがコール中にCRSを楽しむことができるという目的を達成する。

本実施形態で、被呼端末のユーザは、CRSのマルチメディアコンテンツをコール中に継続的に楽しむことができることを期待するものと仮定する。

図7は、図7に示すように、本実施形態のネットワーク構造図である。

MSCサーバ(Mobile Switching Center Server)は、モバイル交換局サーバである。MSCサーバは主に、MSCのコール制御およびモバイル制御によって形成され、CSドメインにおいて、コール処理などの機能を達成する責任を負う。MSCサーバは、ユーザ-ネットワーク信号伝達を終了させ、ユーザ-ネットワーク信号伝達をネットワーク-ネットワーク信号伝達に変換する。MSCサーバは、MGW内のメディアチャネルの一部のコール状態を制御することができ、そのメディアチャネルの一部は接続制御に属する。

VLR(Visitor Location Register)はビジタロケーションレジスタである。VLRは、CSドメインの特殊なデバイスであり、制御エリアにアクセスする登録ユーザの関連情報を保存し、モバイルユーザのためにコール接続の必要なデータを提供する。

MGW(Media Gateway)は、メディアゲートウェイである。MGWは、公衆交換電話網(PSTN)/地上波公共移動通信ネットワーク(PLMN)の伝送終端点であり、luインターフェースを介してコアネットワークおよびUTRANを接続する。MGWは、メディア変換、ベアラ制御およびペイロード処理、たとえば、マルチメディアデータ信号符号器、エコーキャンセラ、およびカンファレンスブリッジなど、をサポートすることができる。

HLR(Home Location Register)は、ホームロケーションレジスタである。HLRは、CSドメインおよびPSドメインの公衆デバイスであり、モバイルユーザを管理する責任を負うデータベースシステムである。HLRは、たとえば、IDフラグ、ロケーション情報、および加入サービスなど、ホームエリアにおけるすべてのモバイルユーザのデータを保存する。

AuC(Authentication Center)は認証センタである。AuCは、ユーザの認証アルゴリズムおよび暗号化鍵を保存するエンティティである。AuCは、通信の妥当性およびセキュリティを確保するために、HLRを介してVLR、MSCおよびSGSNに認証および暗号化データを送信する。

CRSサーバは、カスタマイズされた呼出し信号サーバである。CRSサーバは、CSドメイン内のCRSシステムのコア構成要素であり、CRSのサービスロジックを保存し、マルチメディアリソースを再生するように構成される。

図8は、本実施形態のコールプロセスの概略図である。図8に示すように。

ステップ801:起呼端末UE-Aが、コールを初期化するために、MSCサーバAにSETUPメッセージを送信する。

ステップ802:MSCサーバAが、被呼端末UE-Bのルーティング情報を取得するために、HLRにSRI要求を開始する。

ステップ803:HLRが、UE-Bが添付されたMSCサーバB内のVLRからローミング番号を取得する。

ステップ804:MSCサーバB内のVLRがHLRにPRN_ACKメッセージを返し、そのメッセージがUE-Bのローミング番号を運ぶ。

ステップ805:HLRがSRI-ACKメッセージをMSCサーバAに返し、そのメッセージがUE-Bのルーティング情報およびローミング番号と、ユーザBのためのユーザAによってカスタマイズされたCRSサービスのCRSサービスフラグとを運ぶ。

ステップ806:MSCサーバAが、MSCサーバAがコール動作を実行していることを指示すために、UE-AにCall_Proceedingを起動する。

ステップ807:MSCサーバAが、CRSサーバへの回路接続を確立するために、CRSサーバにベアラ独立呼制御(BICC)初期アドレスメッセージ(IAM)メッセージを起動し、そのIAMメッセージがCRSサービスフラグを運ぶ。CRSサーバは、CRSサービスフラグにしたがって、ユーザBのためのユーザAによってカスタマイズされたCRSサービスを判定する。

ステップ808:CRSサーバが、MSCサーバBへの回路接続を確立するために、BICC IAMメッセージをMSCサーバBに送信し、そのIAMメッセージがCRSサービスフラグを運ぶ。

ステップ809:MSCサーバBが、UE-Bへのページング要求メッセージPAGINGを起動する。

ステップ8010:UE-Bが、ページング応答メッセージPAGING _RSPを返す。

ステップ8011:MSCサーバBが、被呼端末UE-Bとのコール接続を確立するために、UE-BにSETUPメッセージを送信する。そのSETUPメッセージがCRSサービスフラグを運ぶ。CRSサービスフラグを受信した後、UE-BがローカルCRSを抑制し、CRSの受信を待つ。

ステップ8012:UE-Bが、SETUPメッセージに応答するために、Call_Confirmedメッセージを返す。

ステップ8013:UE-Bが鳴り、ALERTINGメッセージをMSCサーバBに返す。

ステップ8014からステップ8015:MSCサーバBが、コールされた末端オフィスにある対応する中継回線が確立されていることを確認するために、CRSサーバを介してMSCサーバAにBICCアドレス完了メッセージ(ACM)メッセージを返す。

ステップ8016:MSCサーバAがUE-AにALERTINGメッセージを送信し、UE-AがCATを生成する。

ステップ8017:H.245接続がCRSサーバおよびUE-Bの間に確立され、メディアチャネルがH.245プロトコルを介して確立される。この時点で、CRSサーバが、UE-BのためのCRSの再生を開始する。

ステップ8018:被呼端末UE-Bはオフフックであり、リプレイメッセージCONNECTを送信する。本実施形態の本方法によれば、CONNECTメッセージがミキシング要求フラグを運び、特定の運搬方式は、そのフラグがCONNECTメッセージのユーザ間セルまたはファシリティセルによって運ばれうるというものでもよい。

ステップ8019:MSCサーバBが、BICC返答メッセージ(ANM)をCRSサーバに送信する。本実施形態の本方法によれば、ANMメッセージはミキシング要求フラグを運び、特定の運搬方式は、そのフラグがANMの任意選択部分内のユーザ間またはファシリティなどの任意選択パラメータによって運ばれうるというものでもよい。CRSサーバが、受信ミキシング要求フラグにしたがってサーバ内のミックスユニットをトリガし、CRSおよびビデオコールプロセスにオーディオミキシング/ミキシングを実行する準備をする。

ステップ8020:MSCサーバBが、肯定応答メッセージCONNECT_ACKを被呼端末UE-Bに返す。

ステップ8021:CRSサーバが、BICC ANMメッセージをMSCサーバAに送信する。

ステップ8022からステップ8023:MSCサーバAがCONNECTメッセージをUE-Aに送信し、UE-Aが肯定応答のためのCONNECT_ACKを返す。

ステップ8024:H.245接続がUE-AおよびCRSサーバの間で確立され、メディアチャネルがH.245プロトコルを介して確立される。発呼者および被呼者が、会話を開始する。

本実施形態の本方法によれば、CRSサーバ内のミックスユニットがCRSおよびUE-AからUE-Bへのオーディオ/ビデオコールストリームにミキシング動作を実行し、混成CRSをUE-Bに送信する。しかし、ミキシング処理は、UE-BからUE-Aへのオーディオ/ビデオコールストリームに実行されない。

ステップ8025:UE-Aはオンフックであり、CRSサーバが、UE-AおよびUE-B間のH.245接続を取り除く。コールが終了する。

本実施形態のステップ8018で、ミキシング要求フラグがCONNECTメッセージによって運ばれることを除いて、ミキシング要求フラグはまた、CONNECTメッセージが送信された後に、USER INFORMATIONメッセージまたはFACILITYメッセージによって運ばれうる。

本実施形態の本方法によれば、実施形態4に対応して、コール中にCRSをCBTに変換する解決法もまたCSドメイン内に実装されうる。実施形態5に対応して、CRSをウェブサーバからダウンロードし、コール中に局所的再生を実行する解決法もまたCSドメイン内で実装されうる。

本実施形態はCSドメインにおけるブリッジ解決法に属するが、本実施形態はCSドメインにおける非ブリッジ解決法にも拡張されうる。原理は同じであり、本明細書において再び詳述はしない。

本実施形態で、サーバはミキシングを実行するために使用されるため、IMSドメインをサポートせず、ミックス機能をもたない端末は、コール中にCRSマルチメディアコンテンツを継続的に再生することを可能にされうる。

実施形態3から実施形態7は、要求端末が被呼端末であり、CRSが被呼端末のために継続的に再生される、またはCRSがコール中に起呼端末および被呼端末のために継続的に再生される状況について提供されることに留意されたい。CATの状況はCRSの状況と同様である。差異は、CATについて、起呼端末が要求端末として供されることと、コール中にCATを継続的に聴くことを要求するために、要求フラグがCAT-ASに送信されることと、CAT-ASが起呼端末によって送信される要求フラグにしたがってコール中にCATの継続的再生をトリガすることとにある。トリガプロセスは、前述の実施形態のそれと同様であり、本明細書において再び詳述はしない。

(実施形態8)
本発明の本実施形態はさらにマルチメディア呼出し音ASを提供し、本実施形態が添付の図面を参照して以下に詳細に説明する。

図9は、本実施形態のマルチメディア呼出し音ASの構成要素の構造ブロック図である。図9に示すように、本実施形態のマルチメディア呼出し音ASは主に、要求フラグ受信ユニット91、およびマルチメディア呼出し音再生トリガユニット93を含む。

要求フラグ受信ユニット91は、起呼端末または被呼端末によって送信される要求フラグを受信するように構成される。

マルチメディア呼出し音再生トリガユニット93は、要求フラグにしたがってコール中のマルチメディア呼出し音の継続的再生をトリガするように構成される。

本実施形態によれば、マルチメディア呼出し音ASはさらに判定ユニット92を含むことができる。本実施形態で、判定ユニット92は、要求フラグのタイプが対応するプロセスをトリガするためのマルチメディア呼出し音再生トリガユニット93に提供されるように、要求フラグ受信ユニット91によって受信される要求フラグにしたがって、要求フラグのタイプを判定するように構成され、その要求フラグはCRSミキシングフラグ、CATミキシングフラグ、CBTミキシングフラグ、マルチメディア呼出し音ダウンロードリンクフラグ、または端末ミックス機能フラグでもよい。

本実施形態によれば、マルチメディア呼出し音再生トリガユニット93は、ミックス指示送信モジュール931を含みうる。本実施形態で、判定ユニット92の判定結果がその要求フラグはCRSミキシングフラグであるというものであるとき、ミックス指示送信モジュール931は、CRSミキシングフラグを運ぶ指示メッセージをMRFに送信して、MRFにCRSおよび起呼端末から被呼端末へのコールメディアストリームのオーディオミキシング/ミキシングを実行するように命令する。

本実施形態で、判定ユニット92の判定結果がその要求フラグはCATミキシングフラグであるというものであるとき、ミックス指示送信モジュール931がCATミキシングフラグを運ぶ指示メッセージをMRFに送信して、CATおよび被呼端末から起呼端末へのコールメディアストリームにオーディオミキシング/ミキシングを実行するようにMRFに命令する。

本実施形態で、判定ユニット92の判定結果がその要求フラグはCBTミキシングフラグであるというものであるとき、ミックス指示送信モジュール931はCBTミキシングフラグを運ぶ指示メッセージをMRFに送信して、CBTと被呼端末および起呼端末間のコールメディアストリームとにオーディオミキシング/ミキシングを実行するようにMRFに命令する。マルチメディア呼出し音再生トリガユニット93はさらに、CBT要求送信モジュール932を含みうる。要求フラグがCBTミキシングフラグであるとき、ミックス指示送信モジュール931が指示メッセージをMRFに送信した後に、CBT要求送信モジュール932が、CBTセッションを交渉するために、CBT要求を起呼端末および被呼端末に送信する。

本実施形態によれば、マルチメディア呼出し音再生トリガユニット93はさらに、リンク指示送信モジュール933、マルチメディア呼出し音リンク受信モジュール934およびマルチメディア呼出し音リンク送信モジュール935を含みうる。本実施形態で、判定ユニット92の判定結果がその要求フラグはマルチメディア呼出し音リンクダウンロードフラグであるというものであるとき、リンク指示送信モジュール933がマルチメディア呼出し音リンクダウンロードフラグを運ぶ指示メッセージをMRFに送信して、マルチメディア呼出し音リンクを送信するようにMRFに命令する。本実施形態で、マルチメディア呼出し音リンク受信モジュール934がMRFによって返されたマルチメディア呼出し音リンクを受信するとき、マルチメディア呼出し音リンク送信モジュール935がマルチメディア呼出し音リンクを運ぶ肯定応答メッセージを要求端末に送信する。

本実施形態によれば、判定ユニット92の判定結果がその要求フラグは端末ミックス機能フラグであるというものであるとき、マルチメディア呼出し音再生トリガユニット93は、CRSが再生されている間に、正規コールプロセスをトリガし、ミックス機能をもつ要求端末が受信CRS/CATおよびコールメディアストリームにミキシングを実行し、局所的再生を実行する。要求端末がコール中に継続的にCRSまたはCATを聴くように実装することもできる。

本実施形態によれば、マルチメディア呼出し音ASはまた、マルチメディア呼出し音サーバに含まれうる。マルチメディア呼出し音サーバはさらにMRFを含み、MRFはCRS/CATおよびコールメディアストリームにミキシングを実行するように、そしてCRSおよび/または混成CRSを再生するように、あるいはCATおよび/または混成CATを再生するように構成される。

マルチメディア呼出し音サーバの構成要素および本実施形態のマルチメディア呼出し音ASは、前述の本方法のステップの機能を実装するように構成される。たとえば、マルチメディア呼出し音ASは前述のCRS-AS、CAT-ASおよび/またはCBT-ASの機能を実装することができ、マルチメディア呼出し音サーバは前述のCRS-AS、CAT-ASおよび/またはCBT-AS、ならびにMRFの機能を実装しうるが、これらは前記で詳述されており、本明細書において再び説明はされることはない。

本実施形態のマルチメディア呼出し音ASを介して、起呼端末、または被呼端末、あるいは起呼端末および被呼端末の両方を、コール中にCRSまたはCATを継続的に聴くことができるようにすることができ、それによって、CRSまたはCATをコール中にユーザのために継続的に再生することができないという先行技術における問題と、コール中にCRSまたはCATをCBTに変換する問題とを解決する。

(実施形態9)
本発明の本実施形態はさらにコール中にマルチメディア呼出し音を再生する方法を提供し、本実施形態は添付の図面を参照して以下に詳細に説明する。

図10は、本実施形態の一方法の流れ図である。本実施形態の本方法は、端末デバイスに適用可能である。図10に示すように、本実施形態の本方法は主に、以下のステップを含む。

1001:マルチメディア呼出し音サーバにマルチメディア呼出し音を継続的に再生するように要求するために使用される要求フラグをマルチメディア呼出し音サーバに送信する。

本実施形態によれば、要求フラグをマルチメディア呼出し音サーバに送信するステップは以下のように説明されうる。

CRSミキシングフラグがマルチメディア呼出し音サーバに送信され、CRSミキシングフラグはCRSおよび起呼端末から被呼端末へのコールメディアストリームのオーディオミキシング/ミキシングを実行し、混成CRSおよびコールメディアストリームを再生するようにマルチメディア呼出し音サーバに要求するために使用される。

本実施形態によれば、要求フラグをマルチメディア呼出し音サーバに送信するステップはまた、以下のように説明されうる。

CATミキシングフラグがマルチメディア呼出し音サーバに送信され、CATミキシングフラグはCATおよび被呼端末から起呼端末へのコールメディアストリームにオーディオミキシング/ミキシングを実行し、混成CATおよびメディアストリームを再生するようにマルチメディア呼出し音サーバに要求するために使用される。

本実施形態によれば、要求フラグをマルチメディア呼出し音サーバに送信するステップもまた、以下のように説明されうる。

CBTミキシングフラグがマルチメディア呼出し音サーバに送信され、そのCBTミキシングフラグはCBTと起呼端末および被呼端末間のコールメディアストリームとにオーディオミキシング/ミキシングを実行し、ミックスされたCBTおよびコールメディアストリームを再生するようにマルチメディア呼出し音サーバに要求するために使用される。

マルチメディア呼出し音リンクダウンロードフラグが、マルチメディア呼出し音サーバに送信され、マルチメディア呼出し音リンクダウンロードフラグは、マルチメディア呼出し音をダウンロードし、局所的再生を実行するために、マルチメディア呼出し音リンクを配信するようにマルチメディア呼出し音サーバに要求するために使用される。

本実施形態で、マルチメディア呼出し音リンクダウンロードフラグをマルチメディア呼出し音サーバに送信するステップの後、本方法はさらに以下のステップを含む。

ステップ1003:マルチメディア呼出し音リンクのマルチメディア呼出し音を受信およびダウンロードする。

ステップ1004:ダウンロードされたマルチメディア呼出し音を局所的に再生する。

端末ミックス機能フラグがマルチメディア呼出し音サーバに送信され、端末ミックス機能フラグは、マルチメディア呼出し音を継続的に再生し、マルチメディア呼出し音および受信コールメディアストリームのオーディオミキシング/ミキシングを実行し、局所的再生を実行するようにマルチメディア呼出し音サーバに要求するために使用される。

本実施形態で、端末ミックス機能フラグをマルチメディア呼出し音サーバに送信するステップの後、本方法はさらに以下のステップを含む。

ステップ1005:受信マルチメディア呼出し音およびコールメディアストリームのオーディオミキシング/ミキシングを実行する。

ステップ1006:コール中にマルチメディア呼出し音の局所的再生を実装するために、混成マルチメディア呼出し音およびコールメディアストリームを再生する。

本実施形態によれば、要求フラグは必ずしも送信される必要はないことがある。発呼者または被呼者は、ユーザがコール中にCRSまたはCATをまだ享受することができるように、帯域外方式でマルチメディア呼出し音サーバに対応する事前設定を実行することができる。

本実施形態の本方法を介して、起呼端末、または被呼端末、あるいは起呼端末および被呼端末の両方がコール中にCRSまたはCATを継続的に聴くことができるようにすることができ、それにより、CRSまたはCATをコール中にユーザのために継続的に再生することができなという先行技術における問題と、コール中にCRSまたはCATをCBTに変換する問題とを解決する。

(実施形態10)
本発明の本実施形態はさらに端末デバイスを提供し、本実施形態が添付の図面を参照して以下に詳細に説明する。

図11は、本実施形態の端末デバイスの構成要素のブロック図である。図11に示すように、本実施形態の端末デバイスは主に、要求フラグをマルチメディア呼出し音サーバに送信するように構成された要求フラグ送信ユニット111を含み、その要求フラグはマルチメディア呼出し音サーバにコール中のマルチメディア呼出し音の継続的再生をトリガするように要求するために使用される。

本実施形態によれば、要求フラグ送信ユニット111は、以下を含みうる:

CRSおよび起呼端末から被呼端末へのコールメディアストリームのオーディオミキシング/ミキシングの実行と、混成CRSおよびコールメディアストリームの再生とをマルチメディア呼出し音サーバに要求するために使用されるCRSミキシングフラグをマルチメディア呼出し音サーバに送信するように構成された、CRSミキシングフラグ送信モジュール1111。

CATおよび被呼端末から起呼端末へのコールメディアストリームのオーディオミキシング/ミキシングの実行と混成CATおよびコールメディアストリームの再生とをマルチメディア呼出し音サーバに要求するために使用されるCATミキシングフラグをマルチメディア呼出し音サーバに送信するように構成された、CATミキシングフラグ送信モジュール1112。

本実施形態によれば、要求フラグ送信ユニット111はさらに以下を含みうる:

CBTと起呼端末および被呼端末間のコールメディアストリームとにオーディオミキシング/ミキシングを実行し、ミックスされたCBTおよびコールメディアストリームを再生するようにマルチメディア呼出し音サーバに要求するために使用されるCBTミキシングフラグをマルチメディア呼出し音サーバに送信するように構成された、CBTミキシングフラグ送信モジュール1113。

本実施形態によれば、要求フラグ送信ユニット111はさらに以下を含む:

マルチメディア呼出し音をダウンロードし、局所的再生を実行するために、マルチメディア呼出し音リンクを配信するようにマルチメディア呼出し音サーバに要求するために使用されるマルチメディア呼出し音リンクダウンロードフラグをマルチメディア呼出し音サーバに送信するように構成された、マルチメディア呼出し音リンクダウンロードフラグ送信モジュール1114。

本実施形態で、端末デバイスはさらに、マルチメディア呼出し音サーバによって配信されるマルチメディア呼出し音リンクを受信するように構成されたマルチメディア呼出し音リンク受信ユニット113と、そのマルチメディア呼出し音リンクにしたがってマルチメディア呼出し音をダウンロードするように構成されたマルチメディア呼出し音ダウンロードユニット114とを含む。

マルチメディア呼出し音を継続的に再生し、マルチメディア呼出し音および受信コールメディアストリームのオーディオミキシング/ミキシングを実行し、局所的再生を実行するようにマルチメディア呼出し音サーバに要求するために使用される端末ミックス機能フラグをマルチメディア呼出し音サーバに送信するように構成された、端末ミックス機能フラグ送信モジュール1115。

本実施形態で、本端末デバイスはさらに、受信マルチメディア呼出し音およびコールメディアストリームのオーディオミキシング/ミキシングを実行するように構成されたミキシングユニット115を含む。

本実施形態によれば、本端末デバイスはさらに以下を含む:

マルチメディア呼出し音ダウンロードユニット114によってダウンロードされたマルチメディア呼出し音またはミキシングユニット115によってミックスされたマルチメディア呼出し音およびコールメディアストリームを再生するように構成された、マルチメディア呼出し音再生ユニット116。

本実施形態の端末デバイスを介して、起呼端末、または被呼端末、あるいは起呼端末および被呼端末の両方を、コール中にCRSまたはCATを継続的に聴くことができるようにすることができ、それによりCRSまたはCATをコール中にユーザのために継続的に再生することができないという先行技術における問題と、コール中にCRSまたはCATをCBTに変換する問題とを解決する。

(実施形態11)
本実施形態のそのネットワーク構造および機能は実施形態3と同じであり、本明細書において再び詳述はされることはない。加えて、本実施形態のアプリケーションシナリオは以下のように説明される。つまり、オペレータまたはユーザは、サーバ上でコール中にCAT/CRSを継続的に再生するポリシを事前設定することができる。被呼端末によって送信されるオフフックメッセージを受信するとき、CRS-ASが対応するサイトリソースを予約するように、またはコール中にオーディオミキシングのためのリソースを予約するようにMRF(マルチメディアリソース機能)に命令し(注:CRS-ASはまた、CRS-ASが発呼者からコール要求メッセージを受信するときに、対応するサイトリソースを予約するように、またはコール中のオーディオミキシングのためのリソースを予約するようにMRFに命令することができる)、そして次に、その後のセッション更新およびオーディオミキシングプロセスを実行する。

図12Aおよび12Bを参照すると、特定のプロセスが以下のように説明される。

ステップ1201からステップ1228は実施形態4におけるステップ401から4028と同じであり、本明細書において再び詳述はしない。

ステップ1229からステップ1231:UE-Bが、P-CSCFおよびS-CSCFを介してCRS-ASに到達するオフフックメッセージを送信する。

ステップ1232からステップ1234:CRS-ASが肯定応答メッセージをUE-Bに返す。

ステップ1235からステップ1236:CRS-ASが、コール中のオーディオミキシングのためのサイトリソースまたはリソースをMRFに要求する。2つのステップはまたステップ1202およびステップ1231の間の任意の時点で実行されうることに留意されたい。

ステップ1237からステップ1239:CRS-ASが、MRFによって生成されたオファSDPを運ぶre-INVITEメッセージをUE-Bに送信し、SDP内のIPアドレスおよびポート番号の両方がMRFに示される。

ステップ1240からステップ1242:UE-Bが、返答SDPを運ぶ応答メッセージをCRS-ASに返す。

ステップ1243:CRS-ASが、MRFによって生成されたオファSDPを運ぶUPDATEメッセージまたはre-INVITEメッセージをUE-Aに送信し、SDP内のIPアドレスおよびポート番号の両方がMRFに示される。

ステップ1244:UE-Aが、返答SDPを運ぶ応答メッセージをCRS-ASに返す。

ステップ1245:CRS-ASが、オフフックメッセージをUE-Aに送信する。

ステップ1246:UE-Aが、肯定応答メッセージをCRS-ASに返す。

ステップ1247からステップ1258は実施形態4のステップ4051からステップ4062と同じであり、本明細書において再び詳述はしない。

CRS-ASがUE-Aから肯定応答メッセージを受信した後、CRS-ASがオーディオミキシング処理を実行するようにMRFに命令する。この時点で、UE-AおよびUE-B間の正規コールが確立される。MRFはミキサの役割を果たし、発呼者および被呼者の間のコールメディアパスに固定される。ミキシング動作が発呼者/被呼者およびCRSメディアのオーディオ/ビデオに実行され、混成CRSメディアが、発呼者および被呼者に送信される。注:コール中、MRFは、CRSメディアに双方向のオーディオミキシングを実行することができ、または単方向オーディオミキシングを実行することもでき、MRFは、発呼者および被呼者の両方にCRSを再生することができ、または発呼者のみにCRSを再生することができ、または被呼者のみにCRSを再生することができる。

本実施形態で提供される本方法の利点は、マルチメディア呼出し音がコール中にユーザのために継続的に再生されるように実装することができ、ユーザはコール中に任意の動作に関わる必要がないということにある。最新の体験がユーザにもたらされ、本技術の実装および促進の利益となる。

(実施形態12)
本実施形態のネットワーク構造およびアプリケーションシナリオは実施形態11と同じであり、本明細書において再び詳述はしない。

図13を参照すると、コール中にマルチメディア呼出し音を再生する方法は、以下のステップを含む。

ステップ1301:被呼端末のオフフックメッセージを受信する。

CRS-ASが被呼端末のオフフックメッセージを受信する。

ステップ1302:メッセージを起呼端末および被呼端末に送信してセッションを更新する。

CRS-ASが、起呼端末に、更新メッセージ(UPDATE)、または新しいセッションを交渉するために使用される要求(SDPオファ)を運ぶコール要求メッセージ(re-INVITE)を送信し、被呼端末に、新しいセッションを交渉するために使用される要求(SDPオファ)を運ぶコール要求メッセージ(re-INVITE)を送信する。起呼端末へのメッセージ送信および被呼端末へのメッセージ送信の順番は限定的ではなく、起呼端末へのメッセージ送信が第一に実行されうる、または被呼端末へのメッセージ送信が第一に実行されうる、または、起呼端末へのメッセージ送信および被呼端末へのメッセージ送信が同時に実行されうる。

ステップ1303:コール中に継続的にマルチメディア呼出し音を再生するために、MRFにオーディオミキシング処理を実行するように命令する。

CRS-ASが、コール中にマルチメディア呼出し音を継続的に再生するために、MRFにオーディオミキシング処理を実行するように命令する。具体的には、CRS-ASが、被呼端末、または起呼端末、または被呼端末および起呼端末の両方にコール中にマルチメディア呼出し音を継続的に再生するために、MRFにマルチメディア呼出し音および正規コールメディアにオーディオミキシング処理を実行するように命令する。

本方法のステップの詳細について、実施形態11と図12Aおよび12Bの関連コンテンツが参照されうる。

(実施形態13)
本実施形態のネットワーク構造およびアプリケーションシナリオは、実施形態11および実施形態12のそれらと同じであり、本明細書において再び詳述はしない。

本実施形態で提供されるマルチメディア呼出し音サーバは、以下を含む:
被呼端末のオフフックメッセージを受信するように構成された、モジュールと、
起呼端末および被呼端末にメッセージを送信してセッションを更新するように構成された、モジュールと、
オーディオミキシング処理を実行してコール中に継続的にマルチメディア呼出し音を再生するようにMRFに命令するように構成された、モジュール。

任意選択で、本マルチメディア呼出し音サーバはさらに以下を含みうる:
被呼端末のオフフックメッセージが受信される前または後に、MRFとコンタクトを取ってコール中のオーディオミキシングのためのサイトリソースまたはリソースを要求するように構成された、モジュール。

任意選択で、メッセージを起呼端末および被呼端末に送信してセッションを更新するように構成されたモジュールは、以下のモジュールのうちの1つを含む:
起呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶ更新メッセージまたはコール要求メッセージを送信し、被呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信するように構成された、モジュールと、
被呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信し、起呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶ更新メッセージまたはコール要求メッセージを送信するように構成された、モジュール。

任意選択で、オーディオミキシング処理を実行して、コール中にマルチメディア呼出し音を継続的に再生するようにMRFに命令するように構成されたモジュールは、具体的には、被呼端末、または起呼端末、または被呼端末および起呼端末の両方のためにコール中にマルチメディア呼出し音を継続的に再生するために、マルチメディア呼出し音および正規コールメディアにオーディオミキシング処理を実行するようにMRFに命令するように構成される。

本実施形態に関わるモジュールによって実行されるステップの詳細について、実施形態11および実施形態12と対応する添付の図面の関連コンテンツが参照されうる。

本実施形態で提供される本方法の利点は、マルチメディア呼出し音がコール中にユーザのために継続的に再生されることが実装されうること、およびユーザはコール中に任意の動作に関わる必要がないことにある。新たな使用環境をユーザにもたらすものであり、このことは技術の推進および促進に恩恵を与えるものである。

本実装の説明を通して、本発明は、ハードウェアを介して、またはソフトウェアに加えた必要なユニバーサルハードウェアプラットフォームを介して、達成されうることが当業者には明らかである。本理解に基づいて、本発明の技術的解決法がソフトウェア製品の形で実施されうる。そのソフトウェア製品は、非揮発性記憶媒体(たとえば、CD-ROM、USBフラッシュドライブ、または取外し可能ハードディスク)内に保存することができ、本発明の実施形態による本方法を実行するようにコンピュータ機器(たとえば、パーソナルコンピュータ、サーバ、またはネットワーク機器)に命令するために使用されるいくつかの命令を含みうる。

本発明の目的、技術的解決法、および有益な効果が、前述の特定の実施形態を介してさらに詳細に説明する。前述の説明は本発明の単に例示的な実施形態であるが、本発明の保護範囲を限定するものではないことを理解されたい。本発明の趣旨および原理を逸脱せずに行われる任意の修正、同等の置換、または改良は、本発明の保護範囲内に含まれるべきである。

91 要求フラグ受信ユニット
92 判断ユニット
93 マルチメディア呼出し音再生トリガユニット
111 要求フラグ送信ユニット
113 マルチメディア呼出し音リンク受信ユニット
114 マルチメディア呼出し音ダウンロードユニット
115 ミキシングユニット
116 マルチメディア呼出し音再生ユニット
931 ミックス指示送信モジュール
932 CBT要求送信モジュール
933 リンク指示送信モジュール
934 マルチメディア呼出し音リンク受信モジュール
935 マルチメディア呼出し音リンク送信モジュール
1111 CRSミキシングフラグ送信モジュール
1112 CATミキシングフラグ送信モジュール
1113 CBTミキシングフラグ送信モジュール
1114 マルチメディア呼出し音リンクダウンロードフラグ送信モジュール
1115 端末ミックス機能フラグ送信モジュール

Claims

コール中にマルチメディア呼出し音を再生する方法であって、
被呼端末のオフフックメッセージを受信する段階と、
起呼端末および前記被呼端末にメッセージを送信してセッションを更新する段階と、
オーディオミキシング処理を実行してコール中にマルチメディア呼出し音を継続的に再生するようにマルチメディアリソース機能(MRF)に命令する段階と
を備え、
オーディオミキシング処理を実行して前記コール中に前記マルチメディア呼出し音を継続的に再生するように前記MRFに命令する前記段階が、
前記コール中に前記起呼端末、および前記被呼端末の少なくとも一方について前記マルチメディア呼出し音を継続的に再生するために、前記マルチメディア呼出し音および正規コールメディアにオーディオミキシングを実行するように前記MRFに命令する段階
を備える、方法。
前記起呼端末および前記被呼端末に前記メッセージを送信して前記セッションを更新する前記段階が、
前記起呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶ更新メッセージまたは新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信する段階と、前記被呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信する段階、あるいは、
前記被呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信する段階と、前記起呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶ更新メッセージまたはコール要求メッセージを送信する段階
を備える、請求項1に記載の方法。
前記被呼端末の前記オフフックメッセージの受信の前または後に、前記MRFとコンタクトを取って前記コール中のオーディオミキシングのためのサイトリソースまたはリソースを要求する段階
をさらに備える、請求項1または2に記載の方法。
被呼端末のオフフックメッセージを受信するように構成された、モジュールと、
起呼端末および前記被呼端末にメッセージを送信してセッションを更新するように構成された、モジュールと、
オーディオミキシング処理を実行してコール中に継続的にマルチメディア呼出し音を再生するようにマルチメディアリソース機能(MRF)に命令するように構成された、モジュールと
を備え、
オーディオミキシングを実行して前記コール中に前記マルチメディア呼出し音を継続的に再生するように前記MRFに命令するように構成された前記モジュールが、具体的には、前記起呼端末、および前記被呼端末の少なくとも一方について前記マルチメディア呼出し音を継続的に再生するために、前記コール中に前記マルチメディア呼出し音および正規コールメディアにオーディオミキシングを実行するように前記MRFに命令するように構成される、マルチメディア呼出し音サーバ。
前記起呼端末および前記被呼端末に前記メッセージを送信して前記セッションを更新するように構成されたモジュールが、
前記起呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶ更新メッセージまたはコール要求メッセージを送信するように、および、前記被呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信するように構成された、モジュールと、
前記被呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶコール要求メッセージを送信するように、および、前記起呼端末に、新しいメディアチャネルを交渉するために使用される要求を運ぶ更新メッセージまたはコール要求メッセージを送信するように構成された、モジュール
のうちの少なくとも1つを備える、請求項4に記載のマルチメディア呼出し音サーバ。
前記被呼端末の前記オフフックメッセージが受信される前または後に、前記MRFとコンタクトを取って前記コール中のオーディオミキシングのためのサイトリソースまたはリソースを要求するように構成された、モジュール
をさらに備える、請求項4または5に記載のマルチメディア呼出し音サーバ。