JP4700105B2

JP4700105B2 - Ｉｐマルチメディアサブシステム（ｉｍｓ）おける呼転送

Info

Publication number: JP4700105B2
Application number: JP2008512697A
Authority: JP
Inventors: アルフヘイデルマルク，; エルブリ，ハンス，エリクヴァン
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2005-05-27
Filing date: 2005-05-27
Publication date: 2011-06-15
Anticipated expiration: 2025-05-27
Also published as: JP2008543135A; CA2609645A1; CN101185305A; ATE412303T1; DE602005010616D1; CN101185305B; US8059633B2; EP1886456A1; WO2006125474A1; EP1886456B1; US20090067411A1

Description

本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）における呼転送に関し、特に、ＩＭＳ内のサービング呼／セション制御機能における呼転送に関係するセション開始プロトコルメッセージを取り扱う方法及び装置に関する。

ＩＰマルチメディアサービスは同じセションの中で音声、ビデオ、メッセージング、データなどの動的組み合わせを提供する。基本アプリケーションと、組み合わせ可能なメディアの数を増やすことにより、エンドユーザに提供されるサービスの数が増え、個人間の通信経験が豊かになるであろう。これは、以下でさらに詳細に考慮する所謂“組み合わせＩＰマルチメディア”サービスを含む、個人的で豊かなマルチメディア通信サービスの新世代に繋がるであろう。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動体通信ネットワーク（３ＧＰＰＴＳ２２．２２８、ＴＳ２３．２１８、ＴＳ２３．２２８、ＴＳ２４．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８、及びＴＳ２９．３２９リリース５及びリリース６）によりＩＰマルチメディアサービスを提供するために第３世代パートナシッププロジェクト（３ＧＰＰ）により定義される技術である。ＩＭＳはエンドユーザの人対人の通信経験を豊かにする重要な特徴を標準化されたＩＭＳサービスイネイブラ（Enablers）の使用を通じて提供する。この標準化されたＩＭＳサービスイネイブラ（Enablers）はＩＰベースのネットワークにより、新しく豊かな人対人（クライアント対クライアント）の通信サービスとともに、人対コンテンツ(クライアント対サーバ）サービスをも容易にする。ＩＭＳはユーザ端末（またはユーザ端末とアプリケーションサーバ)間の呼やセションをセットアップし、制御するためのセション開始プロトコル（ＳＩＰ）を利用する。ＳＩＰシグナリングにより搬送されるセション記述プロトコル（ＳＤＰ）が用いられて、セションのメディア構成要素を記述し、ネゴシエートする。ＳＩＰはユーザ対ユーザのプロトコルとして創成されたが、ＩＭＳによりオペレータおよびサービスプロバイダがサービスへのユーザアクセスを制御し、これに従いユーザに課金することを可能にする。

図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合、移動体ネットワークアーキテクチャにＩＭＳがどのように適合するのかを概略的に示している。呼／セション制御機能（ＣＳＣＦｓ）はＩＭＳによるＳＩＰプロキシとして動作する。３ＧＰＰのアーキテクチャは３つのタイプのＣＳＣＦｓを定義する。即ち、ＳＩＰ端末にとりＩＭＳ内における最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、ユーザが加入するサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）と、正しいＳ−ＣＳＣＦを識別し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信した要求をそのＳ−ＣＳＣＦに転送する役割をもつ問い合わせを行うＣＳＣＦ（Ｉ−ＣＳＣＦ）である。

指定されたＳＩＰＲＥＧＩＳＴＥＲ方法を使用して、ユーザはＩＭＳに登録する。これは、ＩＭＳに所属し、ＳＩＰユーザのアイデンティティに到達できるアドレスをＩＭＳに知らせる機構である。ユーザはＳ−ＣＳＣＦから固有のＵＲＩを受信し、Ｓ−ＣＳＣＦは対話を始める場合に固有のＵＲＩを使用するであろう。３ＧＰＰでＳＩＰ端末が登録を行う場合、ＩＭＳはそのユーザを認証し、利用可能なＳ−ＣＳＣＦのセットからそのユーザにＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰにより規定されていないが、これらは負荷分担およびサービス要求を含むことができる。なお、Ｓ−ＣＳＣＦの割り当てがＩＭＳベースのサービスへのユーザアクセスの制御（およびその課金）に重要である。オペレータは直接のユーザ対ユーザＳＩＰセションを防止する機構を提供することができ、さもなければユーザ対ユーザＳＩＰセションはＳ−ＣＳＣＦをバイパスするであろう。

Ｓ−ＣＳＣＦが既に選択されていなければ、登録の過程でＳ−ＣＳＣＦを選択することはＩ−ＣＳＣＦの責任である。Ｉ−ＣＳＣＦはホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要なＳ−ＣＳＣＦの能力を受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。[なお、ユーザが別の相手により呼を受け、現在ユーザがＳ−ＣＳＣＦを割り当てられていない場合、Ｓ−ＣＳＣＦのユーザへの割り当てもＩ−ＣＳＣＦにより実行される。] 登録したユーザがその後セション要求（例えば、ＳＩＰＩＮＶＩＴＥ）をＩＭＳに送信する場合、その要求はＰ−ＣＳＣＦ及びＳ−ＣＳＣＦＵＲＩを含み、その結果、Ｐ−ＣＳＣＦはその要求を選択されたＳ−ＣＳＣＦに転送することができる。これは（ＩＭＳの）発信側および着信側の両方に当てはまる。［着信呼の場合、その要求はＰ−ＣＳＣＦアドレスとＵＥアドレスとを含むであろう］。

ＩＭＳサービスネットワーク内では、ＩＭＳサービスの機能を実現するために、アプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバはＩＭＳシステムのエンドユーザにサービスを提供し、３ＧＰＰの定義するＭｒインタフェースによりエンドポイントとして接続するか、または３ＧＰＰの定義するＩＳＣインタフェースによりＳ−ＣＳＣＦにより“リンクイン”されても良い。後者の場合、初期フィルタ基準（ＩＦＣ）がＳ−ＣＳＣＦにより使用され、ＳＩＰセション確立中にどのアプリケーションサーバが“リンクイン”されるべきなのかを決定する。ＩＭＳ登録手順の過程でユーザのユーザプロファイルの一部として、ＩＦＣがＨＳＳからＳ−ＣＳＣＦにより受信される。

ＥＴＳＩＴＩＳＰＡＮとして知られるワーキンググループは、固定広帯域アクセスに対するＩＭＳの使用を開発している。そのタスクの１つは、３ＧＰＰにより定義されるＩＭＳに基づいて補完的サービスを開発することである。これら補完的サービスは、ＴＳ２４．２２９などのコア技術仕様に影響するであろうが、別の技術仕様において定義されるであろう。図２は、ＴＳ２４．２２９（第５．４．３．２節）に従う呼の発信側におけるＩＭＳ内のＳＩＰＩＮＶＩＴＥのメッセージフローを模式的に図示している。ステップ１）において、ＩＮＶＩＴＥが発信元のユーザ機器（ＵＥ）からＰ−ＣＳＣＦに送信される。このＩＮＶＩＴＥはそのヘッダに所謂、Ｐ−プリファードアイデンティティを含むとともに、ＳＩＰルートヘッダの最上位レベルにＰ−ＣＳＣＦのＵＲＩと第２のエントリとしてＳ−ＣＳＣＦのＵＲＩを含む。ＵＥはまた、要求ＵＲＩに通信相手のアイデンティティを含む。ＩＮＶＩＴＥを受信すると、Ｐ−ＣＳＣＦは、発信元のＵＥがＰ−プリファードアイデンティティとして含まれるアイデンティティを使用することが許可されていることを調べ、もし許可されていれば、そのアイデンティティをＰ−アサート・アイデンティティとして出力するＩＮＶＩＴＥに含ませる。Ｐ−アサート・アイデンティティは、信頼されたＳＩＰエンティティ、通常は中継者の間で使用され、それが認証により検証されたとき、ＳＩＰメッセージを送信するユーザのアイデンティティを搬送するアイデンティティである。Ｐ−ＣＳＣＦはルートヘッダを見ることにより発信元ＵＥに割り当てられたＳ−ＣＳＣＦを識別し、ステップ２）で、そのＳ−ＣＳＣＦに修正されたＩＮＶＩＴＥを転送する。

Ｓ−ＣＳＣＦは発信呼の手順に従って呼を処理する。Ｓ−ＣＳＣＦはＰ−アサート・アイデンティティを使用して、何か関係する制限が発信元ＵＥに設定されているかどうか、例えば、ＵＥが要求サービスの使用を禁止されているかどうかをチェックする。Ｓ−ＣＳＣＦはまた、Ｐ−アサート・アイデンティティを使用して、そのＵＥに対するＩＦＣを決定する。図２の例では、ＩＦＣはＳ−ＣＳＣＦがＩＮＶＩＴＥを特定のＡＳに転送する（ステップ３））ことを要求するものと想定する。Ｓ−ＣＳＣＦはＳＩＰルートヘッダの最上位レベルにＡＳのＵＲＩを含む。Ｓ−ＣＳＣＦはまた、元々の対話識別子（ＯＤＩ）と共に、それ自身のＵＲＩを次位レベルに含む。ＯＤＩはＳ−ＣＳＣＦにより生成され、Ｓ−ＣＳＣＦへの呼をユニークに識別する。ＡＳがＩＮＶＩＴＥをＳ−ＣＳＣＦに返信する（ステップ４））とき、そのＡＳはルートヘッダからＡＳのＵＲＩを取り除き、ＯＤＩのタグと共にＳ−ＣＳＣＦのＵＲＩを残す。ＯＤＩのタグにより、Ｓ−ＣＳＣＦがそのＩＮＶＩＴＥが以前の対話に関係すると判断することが可能になる。

ＡＳのロジックが新しいセションのセットアップを要求することは可能である。この場合、発信元のアイデンティティ、即ち、ステップ４）におけるＩＮＶＩＴＥのＰ−アサート・アイデンティティは、発信元ＵＥのアイデンティティ、ＡＳのアイデンティティ、或いは、ＡＳが新しいセションを設定しようとする第３の相手のアイデンティティでありうる。この場合、Ｓ−ＣＳＣＦは呼制限のチェックを繰り返し、“新しい”ＩＮＶＩＴＥに含まれるＰ−アサート・アイデンティティに基づいてＩＦＣを決定するであろう。ＩＦＣに基づいて、さらにリンクインするＡＳがないと仮定し、Ｓ−ＣＳＣＦはＩＮＶＩＴＥに含まれる要求ＵＲＩ（Ｒ−ＵＲＩ）にそのＩＮＶＩＴＥを転送する。これは、元々のＩＮＶＩＴＥに含まれるＲ−ＵＲＩ、或いは、それが異なるならば新しいＩＮＶＩＴＥに含まれる新規Ｒ−ＵＲＩであるかもしれない。

図３は、呼の着信側におけるＩＭＳ内のＳＩＰＩＮＶＩＴＥのメッセージフローを模式的に図示している（ＴＳ２４．２２９の第５．４．３．２節）。ステップ１）で被呼者を示すＲ−ＵＲＩを含むＩＮＶＩＴＥがＩ−ＣＳＣＦ（不図示）から着信する。Ｓ−ＣＳＣＦはこのＵＲＩを使用し、被呼者に設定された制限をチェックし、ＩＦＣを取得する。この場合、ＩＦＣはＡＳにコンタクトする必要があることを示唆しない。Ｓ−ＣＳＣＦはＲ−ＵＲＩに基づいて、被呼者についての事前にロードしたルートヘッダを獲得し、これらのルートヘッダのエントリに基づいてＩＮＶＩＴＥをＵＥに転送するであろう。Ｓ−ＣＳＣＦにおける事前にロードされたルートに従って、ＩＮＶＩＴＥはＰ−ＣＳＣＦにより受信され、Ｐ−ＣＳＣＦはコンタクトヘッダに従ってＵＥにＩＮＶＩＴＥを送信する。

図４は、代替のＩＮＶＩＴＥメッセージフローのシナリオを図示している。ここでは、発信元端末（ＵＥ−Ｏ）からピア端末（ＵＥ−Ｆ）への呼が着信端末（ＵＥ−Ｔ）に転送される。呼転送動作はアプリケーションサーバ（ＡＳ−Ｆ）により実行される。呼のフローは以下の通りである。

１）ＩＮＶＩＴＥをＵＥ−ＯからＵＥ−Ｆ（Ｒ−ＵＲＩ）に宛てて送信する。Ｓ−ＣＳＣＦＯは、図２を参照して記述したように発信側の呼の手順を実行する。

２）ＡＳ−Ｏとの相互動作の後（この段階でＲ−ＵＲＩに対して変更を行わない）、Ｓ−ＣＳＣＦＯはＵＥ−ＦのホームネットワークのＩ−ＣＳＣＦ（不図示）にＩＮＶＩＴＥを送信する。Ｉ−ＣＳＣＦは、ＵＥ−ＦがＨＳＳから登録されるＳ−ＣＳＣＦのアドレスを取得する。ＩＮＶＩＴＥはそのＳ−ＣＳＣＦ、即ち、Ｓ−ＣＳＣＦＦに送信される。Ｓ−ＣＳＣＦＦは制限要求をチェックし、（着信側の場合について）図３を参照して上記したように、即ち、ＩＮＶＩＴＥに含まれるＲ−ＵＲＩに基づいてＩＦＣを獲得するであろう。図４に図示されたシナリオでは、呼転送が起動されるＡＳ−ＦにＩＮＶＩＴＥが送信される。

３）ＡＳ−ＦはＩＮＶＩＴＥのヘッダのＲ−ＵＲＩをＵＥ−ＦのＲ−ＵＲＩからＵＥ−ＴのＲ−ＵＲＩへ変更する。修正されたＩＮＶＩＴＥはＳ−ＣＳＣＦＦに返送される。

４）Ｓ−ＣＳＣＦＦはＵＥ−ＴネットワークのＩ−ＣＳＣＦにＩＮＶＩＴＥを送信し、Ｉ−ＣＳＣＦ（不図示）はＨＳＳに問い合わせ、ＵＥ−ＴのＳ−ＣＳＣＦＴのアドレスを得、Ｓ−ＣＳＣＦＴにそのＩＮＶＩＴＥを転送する。

５）Ｓ−ＣＳＣＦＴは、図３を参照して説明したようにＩＮＶＩＴＥに含まれるＲ−ＵＲＩ（即ち、ＵＥ−ＴのＲ−ＵＲＩ）に基づいて、着信手順を実行する。
ＴＳ２４．２２９

再び図４において、ステップ４）では、転送端末ＵＥ−Ｆに制限が存在するかどうかをチェックすることがさらにＳ−ＣＳＣＦＦに必要であろう。これを行うために、Ｓ−ＣＳＣＦは図２の発信側の手順を使用すべきである。しかしながら、ＡＳ−Ｆにより実施される特別の手順が何もない場合、ＡＳ−ＦによりＳ−ＣＳＣＦＦに返送されるＩＮＶＩＴＥは、Ｐ−アサート・アイデンティティのフィールドにＵＥ−Ｏのアイデンティティを含むであろう。Ｓ−ＣＳＣＦＦがＰ−アサート・アイデンティティを使用してＩＮＶＩＴＥについての発信側のチェックを実行するとしても、そのアイデンティティはＳ−ＣＳＣＦＦに“属さ”ない（むしろ、それはＳ−ＣＳＣＦＯに属する）ので、Ｓ−ＣＳＣＦＦはこのアイデンティティについての記録を突き止めることが不可能であろう。これに対して、もしＳ−ＣＳＣＦがＩＮＶＩＴＥについての着信側のチェックを実行すれば、ＩＮＶＩＴＥに含まれるＲ−ＵＲＩがＵＥ−Ｔを識別するので、そのチェックはまた、Ｒ−ＵＲＩがＳ−ＣＳＣＦＦよりむしろＳ−ＣＳＣＦＴに属することに関することとなろう。この問題は、例えば、他の初期要求メッセージ及び独立のメッセージを含むＩＮＶＩＴＥ以外のメッセージにより生じる。

この課題に対する解決策は、ＡＳ−ＦがＵＥ−ＯのＰ−アサート・アイデンティティをＵＥ−Ｆのそれと置換することであるかもしれない。しかしながら、Ｐ−アサート・アイデンティティをエンド・ツー・エンドで不変にしておくことを好むオペレータは、おそらくこれを受け入れないだろう。オペレータの観点からは、Ｐ−アサート・アイデンティティフィールドは、従来（ＰＳＴＮ）の発呼回線のアイデンティティに類似する。それ故、この課題に対する他の解決策を模索しなければならない。

本発明の第１の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、元々の対話識別子と共に前記サービング呼／状態制御機能のＵＲＩを前記メッセージのルートヘッダに追加し、前記元々の対話識別子と前記Ｒ−ＵＲＩとの間の対応付けを前記サービング呼／状態制御機能において維持する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記呼が転送されることになるユーザ機器のＵＲＩに前記メッセージにおける前記Ｒ−ＵＲＩを変更し、前記メッセージに転送指示情報を追加して、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記転送指示情報の存在を識別し、応答として、前記返送されたメッセージに含まれる前記元々の対話識別子に基づいて、元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法が備えられる。

前記処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についてのＩＦＣを識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことが好ましい。

前記転送指示情報は、前記ルートヘッダに含まれることが好ましい。

Ｐ−アサート・アイデンティティは前記Ｓ−ＣＳＣＦにおいて受信する前記メッセージと前記アプリケーションサーバから返送される前記メッセージの両者において同じであり、前記アイデンティティは発信元のユーザ機器を識別することが好ましい。

本発明の第２の側面からすれば、ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバであって、転送指示情報と呼が転送されることになるユーザ機器を識別するＲ−ＵＲＩを含むように、受信されたメッセージを修正することにより、呼転送動作を実施するための処理手段を有することを特徴とするアプリケーションサーバを備える。

本発明の第３の側面からすれば、ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバから受信されたセション開始プロトコルメッセージを処理するための処理手段を有するサービング呼／状態制御機能であって、前記処理手段は、ルートヘッダがセション開始プロトコルのアプリケーションサーバにより追加された転送指示情報を含むかどうかを判断するように動作し、前記処理手段は、前記ルートヘッダが転送指示情報を含めば、前記受信したメッセージに含まれる元々の対話識別子に基づいて元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩに依存して発信手順に従って前記メッセージを処理することを特徴とするサービング呼／状態制御機能を備える。

本発明の第４の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージのＰ−アサート・アイデンティティを前記Ｒ−ＵＲＩに変更して、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記Ｐ−アサート・アイデンティティのフィールドに含まれる前記Ｒ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法を備える。

本発明の第５の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージに転送指示情報を追加し、最上位エントリとして転送ユーザ機器のＳＩＰＵＲＩを含む履歴情報ヘッダを追加する工程と、
前記サービング呼／状態制御機能に前記メッセージを転送する工程と、
前記サービング呼／状態制御機能において、前記メッセージにおける前記転送指示情報の存在を識別し、前記履歴情報ヘッダに含まれるＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法を備える。

本発明の第６の側面からすれば、ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、前記Ｒ−ＵＲＩを格納する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、呼を転送することになるユーザ機器のＲ−ＵＲＩに前記メッセージのＲ−ＵＲＩを変更する工程と、
前記サービング呼／状態制御機能において、前記メッセージのＲ−ＵＲＩにおける変化を識別し、応答として、元々のＲ−ＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法を備える。

本発明は特に、セション開始プロトコルの初期要求メッセージ、例えば、ＩＮＶＩＴＥに、そして、独立のセション開始プロトコルメッセージ、例えば、プレゼンスサービスに関係するメッセージに適用可能である。

本発明の他の側面は、アプリケーションサーバ、及び本発明の第４と第５の側面の特徴を実施する処理手段を有するサービング呼／状態制御機能に関係する。

“転送を行う”Ｓ−ＣＳＣＦがＩＮＶＩＴＥメッセージに関する制限のチェックを実行することを可能にする課題を以上で考察した。アプリケーションサーバからの受信されるＩＮＶＩＴＥをＰ−ＣＳＣＦまたはその他のＣＳＣＦから受信されるＩＮＶＩＴＥとは異なる方法で取り扱う必要がある識別する機構を、転送を行うＳ−ＣＳＣＦに提供することが必要である。

４つの代替的解決策がここで提案される。

解決策１
Ｓ−ＣＳＣＦに着信するＩＮＶＩＴＥは、Ｓ−ＣＳＣＦＦの登録ユーザの１つ、ＵＥ−Ｆを指すＲ−ＵＲＩ、即ち、userf_public1@home2.netをそのヘッダに含む。それはまた、ＵＥ−ＯのＰ−アサート・アイデンティティ、即ち、“John Doe”＜sip:user1_public1@home1.net＞、＜tel:+1-212-555-1111＞を含む。Ｓ−ＣＳＣＦＦは、ルートヘッダの最上位ＵＲＩとして、ＡＳのＳＩＰＵＲＩ、即ち、sip:as1.home1.net;lrを加え、初期要求または独立のトランザクションをＡＳに（ＵＥ−Ｆに対して取得したＩＦＣｓに応答して）送信する。加えて、Ｓ−ＣＳＣＦＦは、“元々の対話識別子”（ＯＤＩ）と共にそれ自身のＳＩＰＵＲＩをルートヘッダのＡＳＵＲＩの下部に含ませる。同時に、Ｓ−ＣＳＣＦＦは、受信したＩＮＶＩＴＥのＲ−ＵＲＩをＯＤＩに結びつけ、この結合をローカルデータベースに格納する。Ｓ−ＣＳＣＦからＡＳ−Ｆに送信されるＩＮＶＩＴＥの構成は図５に示されている。ここで、ルートヘッダに追加されるＳ−ＣＳＣＦＦのＵＲＩは“scscf1.home1.net;lr”であり、ＯＤＩは“cb03a0s09a2sdfglkj490333”である。

ＡＳ−ＦからＳ−ＣＳＣＦＦに返送されるＩＮＶＩＴＥの構成が図６に示されている。ＡＳ−Ｆは到来するＩＮＶＩＴＥにおいて受信する情報を含む。特に、オペレータの要求を満たすために、Ｐ−アサート・アイデンティティは不変である。しかしながら、ＡＳ−Ｆは、呼が転送されることになるＵＥであるＵＥ−ＴのＵＲＩに対応する新しいＲ−ＵＲＩ“usert_public1@home2.net”を追加し、履歴情報ヘッダの拡張部において定義されるように履歴情報ヘッダを追加し、新しい呼処理手順、即ち、転送手順を使用すべきであることをＳ−ＣＳＣＦＦに指示するであろう。このことは、ルートヘッダに“ｆｏｒｗ”パラメータを含ませることにより指示される。

Ｓ−ＣＳＣＦＦがＡＳ−Ｆからそのような修正メッセージを受信すると、“ｆｏｒｗ”パラメータを含むことに基づいて、Ｓ−ＣＳＣＦは呼がＡＳから来ることを知り、Ｓ−ＣＳＣＦＦの自体のＵＲＩに添付されたＯＤＩを判断する。ＯＤＩを使用して、Ｓ−ＣＳＣＦはローカルデータベースからこのＯＤＩに結び付けられたＲ−ＵＲＩ、即ち、転送端末ＵＥ−ＦのＵＲＩを判断する。次いで、Ｓ−ＣＳＣＦＦはＵＥ−ＴのＵＲＩでなく、元々の（即ち、ＵＥ−Ｆの）Ｒ−ＵＲＩに基づいて、制限のチェックとＩＦＣの識別を実行する。［Ｓ−ＣＳＣＦＦとＡＳとの間で全ての相互動作が実行された後、ＴＳ２４．２２９の第５．４．３．２節に始まる段落の動作９乃至１５が実行される］。

解決策２
Ｓ−ＣＳＣＦＦが初期要求をＡＳに送信する場合、Ｓ−ＣＳＣＦＦは現行標準に記載されるようにＵＥ−ＯのＰ−アサート・アイデンティティをＩＮＶＩＴＥに保持する。Ｓ−ＣＳＣＦＦは、ルートヘッダの最上位ＵＲＩとしてＡＳのＳＩＰＵＲＩとともに、それ自体のＳＩＰＵＲＩもＡＳＵＲＩの下部に追加する。Ｓ−ＣＳＣＦからＡＳ−Ｆに送信されるＩＮＶＩＴＥの構成が図７に示されている。

ＡＳ−ＦによるＩＮＶＩＴＥの受信に続いて、ＡＳ−Ｆが呼転送を実行し、Ｒ−ＵＲＩもＵＥ−ＴのＵＲＩに変更すべきであると判断する場合、ＡＳ−Ｆは発呼者のＰ−アサート・アイデンティティを元々のメッセージのＲ−ＵＲＩ、即ち、ＵＥ−ＦのＵＲＩにより置換する。加えて、ＡＳ−Ｆはルートヘッダに“ｏｒｉｇ”パラメータを加え、発信呼のタイプの手順を使用してＩＮＶＩＴＥを扱うべきであることを指示する。ＡＳ−Ｆはまた、メッセージの新しいヘッダフィールドに（ＵＥ−Ｏの）受信されたＰ−アサート・アイデンティティを含ませる。修正されたＩＮＶＩＴＥはＳ−ＣＳＣＦＦに返送され、図８には修正されたＩＮＶＩＴＥが示されている。

修正されたＩＮＶＩＴＥを受信するとき、Ｓ−ＣＳＣＦＦはメッセージのヘッダから、発信呼のタイプの手順を使用して、ＩＮＶＩＴＥを扱うべきであることを知る、即ち、Ｓ−ＣＳＣＦＦはＵＥ−ＦのＲ−ＵＲＩを含むであろうＰ−アサート・アイデンティティに基づいて、制限のチェックを実行し、適切なＩＦＣを決定する。Ｓ−ＣＳＣＦＦはこのＵＲＩの“所有者”であるので、そのチェックは成功裏に実行されるであろう。

ＵＥ−Ｔに関連するＩ−ＣＳＣＦにＩＮＶＩＴＥを転送する前に、Ｓ−ＣＳＣＦＦは、ＩＮＶＩＴＥが再度修正され、ＵＥ−ＦのＲ−ＵＲＩをＵＥ−ＯのＰ−アサート・アイデンティティにより置換しなければならないことを（新しいヘッダにおいて受信する情報から）認識する。このアイデンティティはなお、メッセージのヘッダ内にあるので、Ｓ−ＣＳＣＦＦに容易に利用可能である。“新しいヘッダ”のメッセージにおける存在によりこの動作が起動される契機がつくられる。

解決策３
さらに別の解決策は、Ｓ−ＣＳＣＦが履歴情報ヘッダに含まれる情報の使用を可能にすることである。

Ｓ−ＣＳＣＦＦが初期要求をＡＳに送信するとき、Ｓ−ＣＳＣＦＦは現行標準に記載されるように、ＵＥ−ＯのＰ−アサート・アイデンティティをＩＮＶＩＴＥに保持する。Ｓ−ＣＳＣＦＦは、ルートヘッダの最上位ＵＲＩとしてＡＳのＳＩＰＵＲＩを追加するとともに、それ自体のＳＩＰＵＲＩもＡＳＵＲＩ下部に追加する。Ｓ−ＣＳＣＦからＡＳ−Ｆに送信されるＩＮＶＩＴＥの構成は図９に示されている。ＡＳ−ＦによるＩＮＶＩＴＥの受信に続いて、ＡＳ−Ｆが呼の転送を実行し、ＩＮＶＩＴＥのＲ−ＵＲＩもＵＥ−ＴのＲ−ＵＲＩに変更すべきであると判断する場合、ＡＳ−Ｆは履歴情報ヘッダを追加する。履歴情報ヘッダは履歴情報ヘッダの最上位エントリとしてＵＥ−ＦのＳＩＰＵＲＩを含む。ＡＳはＳ−ＣＳＣＦＦに、新しい呼処理手順、即ち、転送手順を使用すべきであることを指示する。このことは、ルートヘッダに“ｆｏｒｗ”パラメータを含ませることにより指示される。

Ｓ−ＣＳＣＦＦがＡＳ−Ｆからそのような修正されたＩＮＶＩＴＥを受信すると、“ｆｏｒｗ”パラメータを含むことに基づいて、Ｓ−ＣＳＣＦＦは呼がＡＳから来ることを知る。次いで、Ｓ−ＣＳＣＦＦは履歴情報ヘッダの最上位ヘッダ、即ち、ＵＥ−ＦのＵＲＩに基づいて、制限のチェックとＩＦＣの識別とを実行する。

解決策４
この解決策は、（Ｉ−ＣＳＣＦから）Ｓ−ＣＳＣＦＦにおいて受信されるＩＮＶＩＴＥに含まれるＲ−ＵＲＩを格納することが関係している。これはＯＤＩに対して対応付けられても良い。ＡＳはＩＮＶＩＴＥのＲ−ＵＲＩを、ＩＮＶＩＴＥが転送されることになるＵＥ、即ち、ＵＥ−ＴのＲ−ＵＲＩに変更する。Ｓ−ＣＳＣＦＦはＡＳから受信されるＩＮＶＩＴＥのＲ−ＵＲＩについての初期チェックを実行し、それが変更されたかどうかを見る。もし変更されていれば、次いで、元々の（即ち、ＵＥ−Ｆの）Ｒ−ＵＲＩに基づいて、制限のチェックとＩＦＣの決定とが実行される。

本発明の範囲を逸脱することなく、上述した実施例に種々の変更を行うことができることを当業者は認識するであろう。

ＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合を概略的に示した図である。ＩＭＳの発信呼側におけるＳＩＰＩＮＶＩＴＥのフローを示した図である。ＩＭＳの着信呼側におけるＳＩＰＩＮＶＩＴＥのフローを示した図である。ＩＭＳ内の呼転送シナリオにおけるＳＩＰＩＮＶＩＴＥのフローを示した図である。、、、、、ＳＩＰＩＮＶＩＴＥメッセージの構成例を示した図である。

Claims

ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、元々の対話識別子と共に前記サービング呼／状態制御機能のＵＲＩを前記メッセージのルートヘッダに追加し、前記元々の対話識別子と前記Ｒ−ＵＲＩとの間の対応付けを前記サービング呼／状態制御機能において維持する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記呼が転送されることになるユーザ機器のＵＲＩに前記メッセージにおける前記Ｒ−ＵＲＩを変更し、前記メッセージに転送指示情報を追加し、前記サービング呼／状態制御機能に前記メッセージを返送する工程と、
前記サービング呼／状態制御機能において、前記転送指示情報の存在を識別し、応答として、前記対応付けを用いて前記返送されたメッセージに含まれる前記元々の対話識別子に基づいて、元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩを使用して、発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
前記処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についての初期フィルタ基準（ＩＦＣ）を識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項１に記載の方法。
前記転送指示情報は、前記ルートヘッダに含まれることを特徴とする請求項１又は２に記載の方法。
Ｐ−アサート・アイデンティティは前記サービング呼／状態制御機能において受信する前記メッセージと前記アプリケーションサーバから返送される前記メッセージの両者において同じであり、前記アイデンティティは発信元のユーザ機器を識別することを特徴とする請求項１乃至３のいずれか１項に記載の方法。
ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバであって、
転送指示情報と呼が転送されることになるユーザ機器を識別するＲ−ＵＲＩを含むように、受信されたセション開始プロトコルメッセージを修正することにより、呼転送動作を実施するための処理手段を有することを特徴とするアプリケーションサーバ。
ＩＰマルチメディアサブシステムのセション開始プロトコルのアプリケーションサーバから受信されたセション開始プロトコルメッセージを処理するための処理手段を有するサービング呼／状態制御装置であって、
前記処理手段は、ルートヘッダがセション開始プロトコルのアプリケーションサーバにより追加された転送指示情報を含むかどうかを判断するように動作し、
前記処理手段は、前記ルートヘッダが転送指示情報を含めば、前記受信したメッセージに含まれる元々の対話識別子に基づいて、元々のＲ−ＵＲＩと前記元々の対話識別子との間の以前に格納された対応付けを用いて、前記元々のＲ−ＵＲＩを識別し、前記元々のＲ−ＵＲＩに依存して発信手順に従って前記メッセージを処理することを特徴とするサービング呼／状態制御装置。
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、前記メッセージに転送指示情報を追加し、最上位エントリとして転送ユーザ機器のＳＩＰＵＲＩを含む履歴情報ヘッダを追加する工程と、
前記サービング呼／状態制御機能に前記メッセージを転送する工程と、
前記サービング呼／状態制御機能において、前記メッセージにおける前記転送指示情報の存在を識別し、前記履歴情報ヘッダに含まれるＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
前記転送指示情報は、前記メッセージの前記ルートヘッダに含まれることを特徴とする請求項７に記載の方法。
前記サービング呼／状態制御機能において受信した前記メッセージを処理する工程は、前記元々のＲ−ＵＲＩにより識別されるユーザ機器に何らかの制限が設定されているかどうかを判断する工程と、該ユーザ機器についての初期フィルタ基準（ＩＦＣ）を識別する工程と、前記ＩＦＣにより定義されるような更なる処理工程を実行する工程とを含むことを特徴とする請求項７又は８に記載の方法。
ＩＰマルチメディアサブシステム内において、セション開始プロトコルのアプリケーションサーバにより処理される呼転送動作に従うセション開始プロトコルの通信を処理する方法であって、前記方法は、
メッセージのＲ−ＵＲＩにより識別されるユーザ機器にサービスを提供するサービング呼／状態制御機能においてセション開始プロトコルメッセージを受信する工程と、
前記サービング呼／状態制御機能において、前記Ｒ−ＵＲＩを格納する工程と、
前記アプリケーションサーバに前記メッセージを転送する工程と、
前記アプリケーションサーバにおいて、呼を転送することになるユーザ機器のＲ−ＵＲＩに前記メッセージのＲ−ＵＲＩを変更する工程と、
前記サービング呼／状態制御機能において、前記メッセージのＲ−ＵＲＩにおける変化を識別し、応答として、元々のＲ−ＵＲＩを使用して発信手順に従って前記メッセージを処理する工程とを有することを特徴とする方法。
前記セション開始プロトコルのメッセージは、初期要求メッセージ或いは独立のメッセージであることを特徴とする請求項１乃至４、或いは請求項７乃至１０のいずれか１項に記載の方法。
前記セション開始プロトコルのメッセージは、ＩＮＶＩＴＥメッセージであることを特徴とする請求項１１に記載の方法。