JP5260746B2 - エンド・ツー・エンドのアドレス転送 - Google Patents

Description

本発明は、エンド・ツー・エンドのアドレス転送に関し、特に、セッション開始プロトコル（ＳＩＰ）メッセージを使用する通信ネットワークにおけるユニフォーム・リソース・アイデンティファイア（ＵＲＩ）の転送に関する。

ＩＰマルチメディア・サブシステム（ＩＭＳ）は、第３世代パートナーシップ・プロジェクト（３Ｇ）によって定義された、移動体通信ネットワークを介してＩＰマルチメディア・サービスを提供するための技術である。ＩＭＳは、標準化されたＩＭＳサービス・イネーブラの使用を通じてエンドユーザの個人対個人の通信エクスペリエンスを豊かにする鍵となる特徴を提供する。ＩＭＳサービス・イネーブラは、新しい豊かな個人対個人（クライアント対クライアント）の通信を促進する。ＩＭＳネットワークは、インターネットと同様にＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／サービス総合デジタル網）の両方に接続可能である。

ＩＭＳは、同一のセッションの中で、音声、ビデオ、メッセージング、データ等の動的な組み合わせを提供する。基本アプリケーション及び組み合わせ可能なメディアの数が増えることにより、エンドユーザに対して提供されるサービスの数も増えることになり、個人間の通信エクスペリエンスが豊かにされることになる。このことは、所謂「組み合わせＩＰマルチメディア」サービスを含む、パーソナライズされた豊かなマルチメディア通信サービスの新世代を導くことになる。

ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーションサーバとの間）の呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。セッション開始プロトコルは、ＩＥＴＦ(Internet Engineering Task Force)によってＲＦＣ３２６１に規定された、ユーザ間のインタラクティブな通信セッションを開始するためのテキストベースのプロトコルであり、ハイパーテキスト転送プロトコル（ＨＴＴＰ）及びＳＭＴＰ(Simple Mail Transfer Protocol)に似ている。そのようなセッションには、音声、ビデオ、チャット、インタラクティブゲーム、及び仮想現実が含まれる。他の幾つかのＩＥＴＦ仕様書には、ＳＩＰに対する拡張も規定されている。

ＳＩＰによれば、発呼側当事者が呼の開始前に被呼側当事者の現在のＩＰアドレスをたとえ知らなくても、発呼側当事者は、（ユーザ装置（ＵＥ）にインストールされた所謂ＳＩＰユーザエージェント（ＵＡ）を使用して）被呼側当事者に対するパケット交換型セッションを確立することができる。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳによれば、オペレータ及びサービスプロバイダがサービスに対するユーザアクセスを制御し、それに応じて課金することが可能である。

添付図面の図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳがいかにして移動体ネットワークアーキテクチャに適合するかを概略的に示す（もちろん、ＩＭＳは他のアクセスネットワーク上でも動作可能である）。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３Ｇアーキテクチャは、３種類のＣＳＣＦを定義する。即ち、ＳＩＰ端末にとってＩＭＳ内での最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザに対してユーザが加入しているサービスを提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定してＰ−ＣＳＣＦ経由でＳＩＰ端末から受信した要求をそのＳ−ＣＳＣＦへ転送することを役割とするインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。

ＳＩＰは、セッションに関連する様々なサービスを起動できるやり方いう点で柔軟性を提供し、特定のユーザやサービスの直接のコンタクトアドレスを第２のユーザやサービスによって第三者へ転送する必要がある場合があるサービスが存在する。これを行う１つの一般的な方法は、ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ内で受信するＵＲＩを使用することによるものである。Ｃｏｎｔａｃｔヘッダは通常、ＳＩＰエンティティ間の直接の通信を提供するために使用され、後続の要求はＣｏｎｔａｃｔヘッダ内のＵＲＩへ直接向けられることになる。しかしながら、ネットワークによっては、ＳＩＰメッセージのＣｏｎｔａｃｔヘッダが、例えばＳＢＣ(Session Border Controller)や何らかのアプリケーションサーバのようなバック・ツー・バック・ユーザエージェント（Ｂ２ＢＵＡ）のものへとマッピングされて、ユーザやサービスの直接のコンタクトアドレスが受信者のＳＩＰエンティティに届かない場合がある。すると、元々のマッピングを実行した同一のノードがアドレスの逆マッピングを実行する必要があるので、ユーザやサービスへ向けられたメッセージは、元々のマッピングを実行した同一のノードを通過しなければならない。そのような逆マッピングは、メッセージが或るダイアログの中で送信されてメッセージが最初のメッセージと同一のパスを辿る場合にのみ、可能である。

アドレスを第三者へ転送することが必要な場合があるサービスの例は、カンファレンスサービス(conference service)である。図２は、（ＵＥ−Ａ内の）第１のＳＩＰユーザエージェントが「アドホック」カンファレンスを作成し、続いて（ＵＥ−Ｂ内の）第２のＳＩＰユーザエージェントにそのカンファレンスへダイヤルして入るように要求するというシナリオに関する簡略化したシグナリングフローを示す。実行されるステップは以下の通りである。

Ｒ１． ＵＥ−Ａは、ＳＢＣ及びアプリケーションサーバ（ＡＳ）経由で、ＳＩＰサーバ（カンファレンスサーバ又はカンファレンスファクトリ(conference factory)）へＩＮＶＩＴＥ要求を送信する。ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩは、カンファレンスファクトリとして働くＳＩＰサーバのＵＲＩ（ｃｏｎｆ−ｆａｃｔｏｒｙ−ＵＲＩ）にセットされる。

Ｒ２． ＳＩＰサーバは、ＲＦＣ４５７９に規定されているように、ＩＮＶＩＴＥを受け付け、カンファレンスのためのフォーカス(focus)を作成し、カンファレンスフォーカスのＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットされると共に"isfocus"フィーチャータグが付加されたＣｏｎｔａｃｔヘッダを伴う応答をＵＥ−Ａへ送信する。

Ｒ３． この例においてＡＳはＢ２ＢＵＡとして働き、Ｃｏｎｔａｃｔヘッダをやはり"isfocus"フィーチャータグを含んだＡＳのＵＲＩ（ＡＳ−ＵＲＩ）へとマッピングし、応答をＳＢＣへ転送する。

Ｒ４． ＳＢＣもＢ２ＢＵＡとして働き、Ｃｏｎｔａｃｔヘッダを今回も"isfocus"フィーチャータグを含んだ自分のＵＲＩ（ＳＢＣ−ＵＲＩ）へとマッピングし、応答をＵＥ−Ａへ転送する。

Ｒ５． ＵＥ−Ａは、ＲＥＦＥＲ要求を使用して、カンファレンスに参加するようにＵＥ−Ｂに要求する。３ＧＰＰ ＴＳ２４．１４７によれば、Ｒｅｆｅｒ−Ｔｏヘッダは、カンファレンス確立の間に学習されたカンファレンスＵＲＩ（これは、ＳＢＣでのアドレスマッピングが原因で、ＳＢＣ−ＵＲＩである）にセットされる。

Ｒ６． ＲＥＦＥＲは、通常のＳＩＰルーティングを使用して、ＵＥ−Ｂへとルーティングされる。

Ｒ７． カンファレンスに参加しようと試みる際に、ＵＥ−Ｂは、Ｒｅｆｅｒ−Ｔｏヘッダの中のＵＲＩをＲｅｑｕｅｓｔ ＵＲＩとして使用してＩＮＶＩＴＥ要求を送信する。上述の通り、Ｒｅｆｅｒ−ＴｏヘッダはＳＢＣのＵＲＩにセットされているので、ＵＥ−Ｂによって送信されたＩＮＶＩＴＥはＳＢＣへルーティングされ、カンファレンスフォーカスへはルーティングされない。

既存の技術に伴う問題は、第三者（即ち、ＵＥ−Ｂ）が、ユーザやサービスの直接のコンタクトアドレスのマッピングが原因でセッションに参加できないだろうということである。

本発明の目的は、上述の問題を解決するか、少なくとも軽減することである。

本発明の第１の態様によれば、複数のＳＩＰエンティティ間でのＵＲＩのエンド・ツー・エンド転送を促進する方法が提供される。前記方法は、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダの中に含め、前記Ｃｏｎｔａｃｔヘッダの中に、このＵＲＩを変更又は置換してはいけないということをバック・ツー・バック・ユーザエージェントに対して示すパラメータを含めるステップを含む。

本発明の第２の態様によれば、任意の数の中間バック・ツー・バック・ユーザエージェントを介して第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法が提供される。前記方法は、前記第１のＳＩＰエンティティにおいて、ＳＩＰメッセージを生成し、転送対象のＵＲＩをＣｏｎｔａｃｔヘッダの中に含め、前記Ｃｏｎｔａｃｔヘッダの中に、このＵＲＩを変更又は置換してはいけないということをバック・ツー・バック・ユーザエージェントに対して示すパラメータを含め、前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ送信するステップを含む。前記中間バック・ツー・バック・ユーザエージェントにおいて、前記第１のＳＩＰエンティティから前記ＳＩＰメッセージが受信される。前記エンティティは、前記ＵＲＩを変更又は置換してはいけないということを示すパラメータが前記ＳＩＰメッセージの前記Ｃｏｎｔａｃｔヘッダの中に存在することを識別する。前記ＳＩＰエンティティは、前記ＳＩＰメッセージの前記Ｃｏｎｔａｃｔヘッダを変更せずに前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ転送する。

本発明の第３の態様によれば、ＳＩＰエンティティとして動作するように構成された装置が提供される。前記装置は、ＳＩＰメッセージを生成し、転送対象のＵＲＩをＣｏｎｔａｃｔヘッダの中に含め、前記Ｃｏｎｔａｃｔヘッダの中に、このＵＲＩを変更又は置換してはいけないということをバック・ツー・バック・ユーザエージェントに対して示すパラメータを含めるプロセッサを備える。前記装置は、前記ＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機を更に備える。前記装置は、ＳＩＰサーバを含んでもよく、好適にはＳＩＰカンファレンスサーバを含んでもよい。

本発明の第４の態様によれば、バック・ツー・バック・ユーザエージェントとして動作するように構成された装置が提供される。前記装置は、第１のＳＩＰエンティティからＳＩＰメッセージを受信する受信機と、前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダをチェックして前記Ｃｏｎｔａｃｔヘッダの中のＵＲＩを変更又は置換してはいけないということを示すパラメータを探し、前記パラメータが存在する場合、前記Ｃｏｎｔａｃｔヘッダの中のＵＲＩが変更又は置換されないことを確実にするプロセッサと、前記ＳＩＰメッセージを第２のＳＩＰエンティティへ送信する送信機と、を備える。

本発明の第５の態様によれば、複数のＳＩＰエンティティ間でのＵＲＩのエンド・ツー・エンド転送を促進する方法が提供される。前記方法は、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及び前記ＳＩＰメッセージの持続ヘッダの両方に含めるステップを含み、前記持続ヘッダの中のＵＲＩは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされない。

本発明の第６の態様によれば、任意の数の中間バック・ツー・バック・ユーザエージェントを介して第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法が提供される。前記方法は、前記第１のＳＩＰエンティティにおいて、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及び前記ＳＩＰメッセージの持続ヘッダの両方に含めるステップを含む。このようにして、前記持続ヘッダの中のＵＲＩは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされない。前記ＳＩＰメッセージは前記第２のＳＩＰエンティティへ送信される。前記中間バック・ツー・バック・ユーザエージェントにおいて、前記ＳＩＰメッセージは、前記第１のＳＩＰエンティティから受信され、前記ＳＩＰメッセージの前記持続ヘッダを変更せずに前記第２のＳＩＰエンティティへ転送される。

本発明の第７の態様によれば、ＳＩＰエンティティとして動作するように構成された装置が提供される。前記装置は、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及び前記ＳＩＰメッセージの持続ヘッダの両方に含めるプロセッサを備える。前記装置は、前記ＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機を更に備える。前記装置は、ＳＩＰサーバを含んでもよく、好適にはＳＩＰカンファレンスサーバを含んでもよい。

本発明の第８の態様によれば、バック・ツー・バック・ユーザエージェントとして動作するように構成された装置が提供される。前記装置は、第１のＳＩＰエンティティからＳＩＰメッセージを受信する受信機と、前記ＳＩＰメッセージの持続ヘッダの中のＵＲＩが変更又は置換されないことを確実にするプロセッサと、前記ＳＩＰメッセージを第２のＳＩＰエンティティへ送信する送信機と、を備える。

本発明の第９の態様によれば、ＳＩＰエンティティとして動作するように構成された装置が提供される。前記装置は、第１のＳＩＰメッセージを受信する受信機と、前記第１のＳＩＰメッセージをチェックして持続ヘッダを探し、前記持続ヘッダの中にＵＲＩが存在する場合、前記ＵＲＩを含んだ第２のＳＩＰメッセージを生成するプロセッサと、前記第２のＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、を備える。

本発明の第１０の態様によれば、複数のＳＩＰエンティティ間でのＵＲＩのエンド・ツー・エンド転送を促進する方法が提供される。前記方法は、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及びメッセージボディの両方に含めるステップを含み、前記メッセージボディは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされない。

本発明の第１１の態様によれば、任意の数の中間バック・ツー・バック・ユーザエージェントを介して第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法が提供される。前記方法は、前記第１のＳＩＰエンティティにおいて、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及びメッセージボディの両方に含め、前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ送信するステップを含む。前記メッセージボディは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされない。前記中間バック・ツー・バック・ユーザエージェントにおいて、前記ＳＩＰメッセージが、前記第１のＳＩＰエンティティから受信され、前記ＳＩＰメッセージの前記メッセージボディを変更せずに前記第２のＳＩＰエンティティへ転送される。

本発明の第１２の態様によれば、ＳＩＰエンティティとして動作するように構成された装置が提供される。前記装置は、ＳＩＰメッセージのメッセージボディにＵＲＩを含めるプロセッサと、前記ＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、を備える。前記装置は、ＳＩＰサーバを含んでもよく、好適にはＳＩＰカンファレンスサーバを含んでもよい。

本発明の第１３の態様によれば、ＳＩＰエンティティとして動作するように構成された装置が提供される。前記装置は、第１のＳＩＰメッセージを受信する受信機と、前記第１のＳＩＰメッセージを処理し、メッセージボディの中にＵＲＩが存在する場合、前記ＵＲＩを含んだ第２のＳＩＰメッセージを生成するプロセッサと、前記第２のＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、を備える。

本発明の第１４の態様によれば、２以上のＳＩＰユーザ間でカンファレンスコールを確立する方法が提供される。前記方法は、まず、前記２以上のＳＩＰユーザのうちの第１のＳＩＰユーザからＳＩＰカンファレンスサーバへＳＩＰ ＩＮＶＩＴＥを送信するステップを含む。前記ＳＩＰカンファレンスサーバから前記第１のＳＩＰユーザへｃｏｎｆ−ＵＲＩを配信するために、上記態様のいずれか１つに従う、第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法が実行される。前記第１のＳＩＰユーザから他のＳＩＰユーザへ、前記ｃｏｎｆ−ＵＲＩを含んだＳＩＰ ＲＥＦＥＲが送信される。

３Ｇ移動体通信システムに対するＩＰマルチメディア・サブシステムの統合を概略的に示す。 第１のユーザが「アドホック」カンファレンスを作成し、続いて第２のユーザにそのカンファレンスへダイヤルして入るように要求するという既知のシナリオに関するシグナリングフローの例を示す。 図２のシナリオで"nomapping"ＵＲＩパラメータを実装したシグナリングフローの例を示す。 図２のシナリオで"P-Unique-Address"ヘッダを実装した簡略化したシグナリングフローを示す。 図２のシナリオでＳＩＰメッセージボディの中に含まれるＵＲＩを実装したシグナリングフローの例を示す。 ＳＩＰアーキテクチャの例を概略的に示す。

既に論じてきたように、既存の技術を使用すると、ユーザのアドレスを常にエンド・ツー・エンドで転送することは不可能である。これが特に当てはまるのは、セッション開始プロトコル（ＳＩＰ）メッセージのＣｏｎｔａｃｔヘッダが変更される原因となるであろうトポロジ隠蔽及び／又はアイデンティティ隠蔽を発動するかもしれない、例えばＳＢＣ(Session Border Controller)や何らかのアプリケーションサーバ（ＡＳ）のようなバック・ツー・バック・ユーザエージェント（Ｂ２ＢＵＡ）を介した転送を行う場合である。

この問題を克服するために、ここでは、新たなＵＲＩパラメータである"nomapping"を導入することを提案する。ＵＲＩパラメータは、ＵＲＩのhost:portコンポーネントの後に追加され、セミコロンで区切られ（例えば、図３に示すようなsip:conf-URI;nomapping）、ＵＲＩから構築される要求に影響を与える。このパラメータをＵＲＩに追加することにより、Ｂ２ＢＵＡに対して、Ｂ２ＢＵＡがこのＵＲＩをマッピングしてはいけないということを通知することになる。するとＢ２ＢＵＡは、ＳＩＰプロキシサーバのように振る舞う必要があり、ＳＩＰメッセージを転送し、自身のアドレスをＣｏｎｔａｃｔヘッダフィールドにマッピングする代わりにＲｅｃｏｒｄ−ｒｏｕｔｅヘッダに追加する。

図３は、図２のシナリオで"nomapping"ＵＲＩパラメータを実装した簡略化したシグナリングフローを示す。ステップは以下のように続く。

Ｓ１． ＵＥ−Ａは、ＳＢＣ及びＡＳ経由でＳＩＰサーバ（カンファレンスファクトリ）へＩＮＶＩＴＥ要求を送信する。ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩは、カンファレンスファクトリとして働くＳＩＰサーバのＵＲＩ（Ｃｏｎｆ−ｆａｃｔｏｒｙ−ＵＲＩ）にセットされる。

Ｓ２． ＳＩＰサーバがＩＮＶＩＴＥを受け付け、カンファレンスのためのフォーカスを生成し、カンファレンスフォーカスのＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットされると共に"nomapping"ＵＲＩパラメータ及び"isfocus"フィーチャータグが付加されたＣｏｎｔａｃｔヘッダを伴う応答をＵＥ−Ａへ送信する。

Ｓ３． "nomapping"ＵＲＩパラメータの存在により、ＡＳは、自分がＢ２ＢＵＡとして働いているものの応答のＣｏｎｔａｃｔヘッダをマッピングしてはならないということを通知される。するとＡＳは、ＳＩＰプロキシのように振る舞い、Ｃｏｎｔａｃｔヘッダを変更せずに自身のアドレスをＲｅｃｏｒｄ−ｒｏｕｔｅヘッダとして付加して応答をＳＢＣへ転送する。

Ｓ４． 同様に、"nomapping"ＵＲＩパラメータの存在により、ＳＢＣがＣｏｎｔａｃｔヘッダを自身のＵＲＩ（ＳＢＣ−ＵＲＩ）にマッピングすることが防止される。また、ＳＢＣもＳＩＰプロキシのように振る舞い、Ｃｏｎｔａｃｔヘッダを変更せずに自身のアドレスをＲｅｃｏｒｄ−ｒｏｕｔｅヘッダとして付加して応答をＵＥ−Ａへ転送する。

Ｓ５． ＵＥ−Ａは、ＲＥＦＥＲ要求を使用して、ＵＥ−Ｂにカンファレンスに参加するように要求する。Ｒｅｆｅｒ−Ｔｏヘッダは、カンファレンス確立の間に知られたカンファレンスＵＲＩにセットされる。カンファレンスＵＲＩは、"nomapping"ＵＲＩパラメータの存在に起因して、カンファレンスフォーカスのＵＲＩ（ｃｏｎｆ−ＵＲＩ）である。

Ｓ６． ＲＥＦＥＲは、通常のＳＩＰルーティングを使用してＵＥ−Ｂへルーティングされる。

Ｓ７． するとＵＥ−Ｂはカンファレンスに参加しようと試み、Ｒｅｆｅｒ−Ｔｏヘッダの中のＵＲＩをＲｅｑｕｅｓｔ ＵＲＩとして使用してＩＮＶＩＴＥ要求を送信する。上述のように、Ｒｅｆｅｒ−ＴｏヘッダはカンファレンスフォーカスのＵＲＩにセットされるので、ＩＮＶＩＴＥはカンファレンスフォーカスへ正しくルーティングされる。

Ｃｏｎｔａｃｔヘッダの中のＵＲＩは、ＳＩＰ ＵＲＩであってもよいしＳＩＰＳ ＵＲＩであってもよい。ＳＩＰＳ ＵＲＩを使用すると、リソースにセキュアに到達しなければならないということ、特に、相互ＴＬＳ認証を採用しなければならないということをリソースが示すことができる。

問題に対する代替ソリューションとして、新たなＳＩＰヘッダである"P-Unique-Address"を定義することを提案する。"P-Unique-Address"ヘッダは、Ｂ２ＢＵＡがマッピングしてはならないＵＲＩを含むことになる。するとＳＩＰ ＵＡやＳＩＰサーバのようなＳＩＰエンティティは、このヘッダを使用して、自身のアドレスがＢ２ＢＵＡのような中間エンティティによってマッピングされることなくＳＩＰメッセージの受信者（即ち、エンドポイントＳＩＰエンティティ）へ転送可能であるということを確実にすることができる。受信者ＳＩＰエンティティは、このヘッダをチェックし、このフィールド値で与えられたアドレスを使用することができる。新たな"P-Unique-Address"ＳＩＰヘッダを使用する場合、ヘッダの中のＵＲＩは、ＳＩＰ ＵＲＩであってもよいしＳＩＰＳ ＵＲＩであってもよい。これはＴｅｌ ＵＲＩであってもよい。

図４は、図２のシナリオで"P-Unique-Address"ＳＩＰヘッダを実装した簡略化したシグナリングフローを示す。実行されるステップは以下の通りである。

Ｔ１． ＵＥ−Ａは、ＳＢＣ及びＡＳ経由でＳＩＰサーバ（カンファレンスファクトリ）へＩＮＶＩＴＥ要求を送信する。ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩは、カンファレンスファクトリとして働くＳＩＰサーバのＵＲＩ（Ｃｏｎｆ−ｆａｃｔｏｒｙ−ＵＲＩ）にセットされる。

Ｔ２． ＳＩＰサーバがＩＮＶＩＴＥを受け付け、カンファレンスのためのフォーカスを生成し、カンファレンスフォーカスのＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットされたＣｏｎｔａｃｔヘッダを伴う応答をＵＥ−Ａへ送信し、"isfocus"フィーチャータグを付加する。加えて、カンファレンスファクトリは"P-Unique-Address"ヘッダを応答の中に付加し、このヘッダを"isfocus"フィーチャータグを伴うカンファレンスフォーカスＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットする。

Ｔ３． Ｂ２ＢＵＡとして振る舞うＡＳは、Ｃｏｎｔａｃｔヘッダを、"isfocus"フィーチャータグも含んだＡＳのＵＲＩ（ＡＳ−ＵＲＩ）にマッピングし、応答をＳＢＣへ転送する。ＡＳは"P-Unique-Address"ヘッダの中のＵＲＩは変更しないままにしておく。

Ｔ４． ＳＢＣもＢ２ＢＵＡとして振る舞い、Ｃｏｎｔａｃｔヘッダを、やはり"isfocus"フィーチャータグを含んだ自身のＵＲＩ（ＳＢＣ−ＵＲＩ）にマッピングし、応答をＵＥ−Ａへ転送する。ＳＢＣも"P-Unique-Address"ヘッダの中のＵＲＩは変更しないままにしておく。

Ｔ５． ＵＥ−Ａは、ＲＥＦＥＲ要求を使用して、ＵＥ−Ｂにカンファレンスに参加するように要求する。ＵＥ−Ａは、"P-Unique-Address"ヘッダをチェックし、フィールド値の中のＵＲＩを使用してＲｅｆｅｒ−ＴｏヘッダをカンファレンスフォーカスＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットする。

Ｔ６． ＲＥＦＥＲは、通常のＳＩＰルーティングを使用してＵＥ−Ｂへルーティングされる。

Ｔ７． するとＵＥ−Ｂはカンファレンスに参加しようと試み、Ｒｅｆｅｒ−Ｔｏヘッダの中のＵＲＩをＲｅｑｕｅｓｔ ＵＲＩとして使用してＩＮＶＩＴＥ要求を送信する。上述のように、Ｒｅｆｅｒ−ＴｏヘッダはカンファレンスフォーカスのＵＲＩにセットされるので、ＩＮＶＩＴＥはカンファレンスフォーカスへ正しくルーティングされる。

問題に対する第３の代替ソリューションとして、ＵＲＩをＳＩＰメッセージのボディ中に含めてもよい。ＳＩＰメッセージによって搬送されるメッセージボディは、通常は（セッション記述プロトコル（ＳＤＰ）を使用した）セッション記述であるが、任意のテキストベースの情報を搬送可能である。通常は、プロキシ又はＢ２ＢＵＡがメッセージボディを検査したり変更したりする必要が無いように、ＳＩＰメッセージをルーティングするのに必要な全ての情報がスタートライン及びヘッダの中に含まれる。その結果、メッセージボディは変更されずにエンド・ツー・エンドで送信される。するとメッセージの最終受信者は、ボディを含んだＳＩＰメッセージを処理し、リダイレクトのために使用すべきＵＲＩをボディが含むか否かを判定することができる。ボディは暗号化されていてもよいし、暗号化されていなくてもよい。新たな"P-Unique-Address"ＳＩＰヘッダを使用する場合と同様、ＳＩＰメッセージのボディの中にＵＲＩを配置する場合、ＵＲＩはＳＩＰ ＵＲＩであってもＳＩＰＳ ＵＲＩであってもよく、或いはＴｅｌ ＵＲＩであってもよい。

再び図２に示すシナリオを参照して、図５は、ＳＩＰメッセージボディの中に含まれるＵＲＩを実装した簡略化したシグナリングフローを示す。実行されるステップは以下の通りである。

Ｕ１． ＵＥ−Ａは、ＳＢＣ及びＡＳ経由でＳＩＰサーバ（カンファレンスファクトリ）へＩＮＶＩＴＥ要求を送信する。ＩＮＶＩＴＥのＲｅｑｕｅｓｔ−ＵＲＩは、カンファレンスファクトリとして働くＳＩＰサーバのＵＲＩ（Ｃｏｎｆ−ｆａｃｔｏｒｙ−ＵＲＩ）にセットされる。

Ｕ２． ＳＩＰサーバがＩＮＶＩＴＥを受け付け、カンファレンスのためのフォーカスを生成し、カンファレンスフォーカスのＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットされると共に"isfocus"フィーチャータグが付加されたＣｏｎｔａｃｔヘッダを伴う応答をＵＥ−Ａへ送信する。加えて、カンファレンスファクトリは、カンファレンスフォーカスのＵＲＩを応答のボディの中に挿入する。

Ｕ３． Ｂ２ＢＵＡとして振る舞うＡＳは、Ｃｏｎｔａｃｔヘッダを、"isfocus"フィーチャータグも含んだＡＳのＵＲＩ（ＡＳ−ＵＲＩ）にマッピングし、応答をＳＢＣへ転送する。ＡＳはメッセージのボディを変更しないままにしておき、従ってカンファレンスフォーカスのＵＲＩは変更されないままである。

Ｕ４． ＳＢＣはアイデンティティ／トポロジ隠蔽を適用し、Ｃｏｎｔａｃｔヘッダを、やはり"isfocus"フィーチャータグを含んだ自身のＵＲＩ（ＳＢＣ−ＵＲＩ）にマッピングし、応答をＵＥ−Ａへ転送する。ＳＢＣもメッセージのボディを変更しないままにしておき、従ってカンファレンスフォーカスのＵＲＩは変更されないままである。

Ｕ５． 応答を処理することの一部として、ＵＥ−Ａは、メッセージをカンファレンスファクトリへリダイレクトするために使用可能なＵＲＩをメッセージボディが含んでいるということを識別する。ＵＥ−ＡがＲＥＦＥＲ要求を使用してＵＥ−Ｂにカンファレンスに参加するよう要求する際に、Ｒｅｆｅｒ−Ｔｏヘッダは、メッセージボディの中で発見されたＵＲＩ（ｃｏｎｆ−ＵＲＩ）にセットされる。

Ｕ６． ＲＥＦＥＲは、通常のＳＩＰルーティングを使用してＵＥ−Ｂへルーティングされる。

Ｕ７． するとＵＥ−Ｂはカンファレンスに参加しようと試み、Ｒｅｆｅｒ−Ｔｏヘッダの中のＵＲＩをＲｅｑｕｅｓｔ ＵＲＩとして使用してＩＮＶＩＴＥ要求を送信する。上述のように、Ｒｅｆｅｒ−ＴｏヘッダはカンファレンスフォーカスのＵＲＩにセットされるので、ＩＮＶＩＴＥはカンファレンスフォーカスへ正しくルーティングされる。

上述のメカニズムにより、ネットワークを介してＵＲＩを透過的に転送することが可能になる。このことは、ユーザがこのＵＲＩを他のユーザへ送信可能であるという利点を提供し、それゆえ、この他のユーザがそのＵＲＩによって特定されるサービスを使用することが可能になる。カンファレンスコールはそのようなサービスの一例であり、ＵＲＩが特定のカンファレンスセッションを識別する。そのようなサービスの他の例はゲーミングサービスであり、ＵＲＩが特定のゲームセッションを識別する。特定のアイデンティティによって識別されるサービスにユーザがアクセスする必要のある多くの類似した例が考えられる。

図６は、上述のシナリオが発生し得るＳＩＰアーキテクチャの例を概略的に示す。このアーキテクチャは、３つのＳＩＰエンティティを含む。即ち、ＳＩＰサーバ１、第１のＳＩＰユーザエージェント２及び第２のＳＩＰユーザエージェント３、並びに、バック・ツー・バック・ユーザエージェント４である。

ＳＩＰサーバ１は、例えば上述のカンファレンスサーバ又はカンファレンスファクトリのように、サービス促進に適しており、プロセッサ５、送信機６、及び受信機７を含む。プロセッサ５は、以下の実行により、上述のいずれか又は全てのソリューションを実装するのに適している。
１．Ｃｏｎｔａｃｔヘッダを含むＳＩＰメッセージを生成し、自身のＵＲＩを'nomapping'パラメータと共にＣｏｎｔａｃｔヘッダに挿入することによって、又は、
２．P-Unique-Addressヘッダを含むＳＩＰメッセージを生成し、自身のＵＲＩをこのヘッダの中に挿入することによって、又は、
３．ＳＩＰメッセージを生成し、自身のＵＲＩをメッセージボディの中に挿入することによって。

このＳＩＰメッセージは、次に、送信機６を使用して第１のＳＩＰユーザエージェント２へ送信される。

ＳＩＰサーバ１からＳＩＰユーザエージェント２へ送信されるこのＳＩＰメッセージは、バック・ツー・バック・ユーザエージェント４を横断しなければならない。バック・ツー・バック・ユーザエージェント４は、上述のようにアイデンティティ隠蔽及び／又はトポロジ隠蔽に適しており、受信機８、プロセッサ９、及び送信機１０を含む。受信機８は、ＳＩＰサーバ１から送信されたＳＩＰメッセージを受信する。次にプロセッサ９は、以下の実行により、上述のいずれか又は全てのソリューションを実装するために必要なように、このメッセージを処理する。
１．ＳＩＰメッセージのＣｏｎｔａｃｔヘッダをチェックして'nomapping'パラメータを探し、このパラメータが存在する場合、Ｃｏｎｔａｃｔヘッダの中のＵＲＩを変更しないままＳＩＰメッセージを処理することによって、又は、
２．P-Unique-Addressヘッダの中のＵＲＩを変更しないままＳＩＰメッセージを処理することによって、又は、
３．メッセージボディの中のＵＲＩを変更しないままＳＩＰメッセージを処理することによって。

このＳＩＰメッセージは、次に、送信機１０を使用して第１のＳＩＰユーザエージェント２へ送信される。

第１のユーザエージェント２は、上述のように、ユーザ又はサービスのＵＲＩを第三者へ送信するのに適しており、受信機１１、プロセッサ１２、及び送信機１３を含む。受信機１１は、ＳＩＰサーバ１から送信されたＳＩＰメッセージを、バック・ツー・バック・ユーザエージェント４を介して受信する。次にプロセッサ１２は、以下の実行により、上述のいずれか又は全てのソリューションを実装するために必要なように、このメッセージを処理する。
１．Ｃｏｎｔａｃｔヘッダの中で発見されたＵＲＩを含んだ第２のＳＩＰメッセージを生成することによって、又は、
２．ＳＩＰメッセージをチェックしてＵＲＩを含んだP-Unique-Addressヘッダを探し、P-Unique-Addressが存在する場合、そのＵＲＩを含んだ第２のＳＩＰメッセージを生成することによって、又は、
ＳＩＰメッセージのボディをチェックしてＵＲＩを探し、メッセージボディがＵＲＩを含んでいる場合、そのＵＲＩを含んだ第２のＳＩＰメッセージを生成することによって。

第２のＳＩＰメッセージは、次に、送信機１３を使用して第２のＳＩＰユーザエージェント３へ送信される。

第２のＳＩＰユーザエージェント３は、上述のように第三者によってそこへ送信されたＵＲＩを使用してＳＩＰユーザ又はサービスとセッションを確立するのに適しており、受信機１４、プロセッサ１５、及び送信機１６を含む。受信機１４は、第１のＳＩＰユーザエージェント２から送信された第２のＳＩＰメッセージを受信する。次にプロセッサ１５は、セッションを確立するために必要なように、このメッセージを処理する。第３のＳＩＰメッセージが、次に、送信機１６を使用してＳＩＰサーバ１へ送信される。

当業者によって理解されるであろうこととして、本発明の範囲から逸脱することなしに上述の実施形態に対して様々な変更を加えることができる。

Claims (16)

1. 複数のＳＩＰエンティティ間でのＵＲＩのエンド・ツー・エンド転送を促進する方法であって、
   ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダの中に含め、前記Ｃｏｎｔａｃｔヘッダの中に、このＵＲＩを変更又は置換してはいけないということをバック・ツー・バック・ユーザエージェントに対して示すパラメータを含めるステップ
   を含むことを特徴とする方法。
2. 任意の数の中間バック・ツー・バック・ユーザエージェントを介して第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法であって、
   前記第１のＳＩＰエンティティにおいて、ＳＩＰメッセージを生成し、転送対象のＵＲＩをＣｏｎｔａｃｔヘッダの中に含め、前記Ｃｏｎｔａｃｔヘッダの中に、このＵＲＩを変更又は置換してはいけないということをバック・ツー・バック・ユーザエージェントに対して示すパラメータを含め、前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ送信するステップと、
   前記中間バック・ツー・バック・ユーザエージェントにおいて、前記第１のＳＩＰエンティティから前記ＳＩＰメッセージを受信し、前記ＵＲＩを変更又は置換してはいけないということを示す前記パラメータが前記ＳＩＰメッセージの前記Ｃｏｎｔａｃｔヘッダの中に存在することを識別し、前記ＳＩＰメッセージの前記Ｃｏｎｔａｃｔヘッダを変更せずに前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ転送するステップと、
   を含むことを特徴とする方法。
3. ＳＩＰエンティティとして動作するように構成された装置であって、
   ＳＩＰメッセージを生成し、転送対象のＵＲＩをＣｏｎｔａｃｔヘッダの中に含め、前記Ｃｏｎｔａｃｔヘッダの中に、このＵＲＩを変更又は置換してはいけないということをバック・ツー・バック・ユーザエージェントに対して示すパラメータを含めるプロセッサと、
   前記ＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、
   を備えることを特徴とする装置。
4. バック・ツー・バック・ユーザエージェントとして動作するように構成された装置であって、
   第１のＳＩＰエンティティからＳＩＰメッセージを受信する受信機と、
   前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダをチェックして前記Ｃｏｎｔａｃｔヘッダの中のＵＲＩを変更又は置換してはいけないということを示すパラメータを探し、前記パラメータが存在する場合、前記Ｃｏｎｔａｃｔヘッダの中のＵＲＩが変更又は置換されないことを確実にするプロセッサと、
   前記ＳＩＰメッセージを第２のＳＩＰエンティティへ送信する送信機と、
   を備えることを特徴とする装置。
5. 複数のＳＩＰエンティティ間でのＵＲＩのエンド・ツー・エンド転送を促進する方法であって、
   ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及び前記ＳＩＰメッセージの持続ヘッダの両方に含めるステップを含み、
   前記持続ヘッダの中のＵＲＩは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされない
   ことを特徴とする方法。
6. 任意の数の中間バック・ツー・バック・ユーザエージェントを介して第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法であって、
   前記第１のＳＩＰエンティティにおいて、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及び前記ＳＩＰメッセージの持続ヘッダの両方に含め、前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ送信するステップを含み、
   前記持続ヘッダの中のＵＲＩは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされず、
   前記方法は、
   前記中間バック・ツー・バック・ユーザエージェントにおいて、前記ＳＩＰメッセージを前記第１のＳＩＰエンティティから受信し、前記ＳＩＰメッセージの前記持続ヘッダを変更せずに前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ転送するステップを含む
   ことを特徴とする方法。
7. ＳＩＰエンティティとして動作するように構成された装置であって、
   ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及び前記ＳＩＰメッセージの持続ヘッダの両方に含めるプロセッサと、
   前記ＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、
   を備えることを特徴とする装置。
8. バック・ツー・バック・ユーザエージェントとして動作するように構成された装置であって、
   第１のＳＩＰエンティティからＳＩＰメッセージを受信する受信機であって、前記ＳＩＰメッセージはＣｏｎｔａｃｔヘッダの中にＵＲＩを含むと共に持続ヘッダの中にも当該ＵＲＩを含む、受信機と、
   前記ＳＩＰメッセージの前記持続ヘッダを認識し、当該持続ヘッダの中の前記ＵＲＩが変更又は置換されないことを確実にするプロセッサと、
   前記ＳＩＰメッセージを第２のＳＩＰエンティティへ送信する送信機と、
   を備えることを特徴とする装置。
9. ＳＩＰエンティティとして動作するように構成された装置であって、
   第１のＳＩＰメッセージを受信する受信機であって、前記第１のＳＩＰメッセージはＣｏｎｔａｃｔヘッダの中に第１のＵＲＩを含むと共に持続ヘッダの中に第２のＵＲＩを含む、受信機と、
   前記第１のＳＩＰメッセージをチェックして前記持続ヘッダを探し、前記持続ヘッダの中に前記第２のＵＲＩが存在する場合、前記第２のＵＲＩを含んだ第２のＳＩＰメッセージを生成するプロセッサと、
   前記第２のＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、
   を備えることを特徴とする装置。
10. 複数のＳＩＰエンティティ間でのＵＲＩのエンド・ツー・エンド転送を促進する方法であって、
    ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及びメッセージボディの両方に含めるステップを含み、
    前記メッセージボディは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされない
    ことを特徴とする方法。
11. 任意の数の中間バック・ツー・バック・ユーザエージェントを介して第１のＳＩＰエンティティから第２のＳＩＰエンティティへＵＲＩを転送する方法であって、
    前記第１のＳＩＰエンティティにおいて、ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及びメッセージボディの両方に含め、前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ送信するステップを含み、
    前記メッセージボディは、バック・ツー・バック・ユーザエージェントによって変更又は置換をされず、
    前記方法は、
    前記中間バック・ツー・バック・ユーザエージェントにおいて、前記ＳＩＰメッセージを前記第１のＳＩＰエンティティから受信し、前記ＳＩＰメッセージの前記メッセージボディを変更せずに前記ＳＩＰメッセージを前記第２のＳＩＰエンティティへ転送するステップを含む
    ことを特徴とする方法。
12. ＳＩＰエンティティとして動作するように構成された装置であって、
    ＳＩＰメッセージを生成し、転送対象のＵＲＩを前記ＳＩＰメッセージのＣｏｎｔａｃｔヘッダ及びメッセージボディの両方に含めるプロセッサと、
    前記ＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、
    を備えることを特徴とする装置。
13. ＳＩＰエンティティとして動作するように構成された装置であって、
    第１のＳＩＰメッセージを受信する受信機であって、前記第１のＳＩＰメッセージはＣｏｎｔａｃｔヘッダの中に第１のＵＲＩを含むと共にメッセージボディの中に第２のＵＲＩを含む、受信機と、
    前記第１のＳＩＰメッセージを処理し、前記メッセージボディの中に前記第２のＵＲＩが存在する場合、前記第２のＵＲＩを含んだ第２のＳＩＰメッセージを生成するプロセッサと、
    前記第２のＳＩＰメッセージを他のＳＩＰエンティティへ送信する送信機と、
    を備えることを特徴とする装置。
14. ＳＩＰサーバであることを特徴とする請求項３、７、又は１２に記載の装置。
15. ＳＩＰカンファレンスサーバであることを特徴とする請求項１４に記載の装置。
16. ２以上のＳＩＰユーザ間でカンファレンスコールを確立する方法であって、
    前記２以上のＳＩＰユーザのうちの第１のＳＩＰユーザからＳＩＰカンファレンスサーバへＳＩＰ ＩＮＶＩＴＥを送信するステップと、
    前記ＳＩＰカンファレンスサーバから前記第１のＳＩＰユーザへｃｏｎｆ−ＵＲＩを配信するために請求項２、６、又は１１に記載の方法を実行するステップと、
    前記第１のＳＩＰユーザから他のＳＩＰユーザへ、前記ｃｏｎｆ−ＵＲＩを含んだＳＩＰ ＲＥＦＥＲを送信するステップと、
    を含むことを特徴とする方法。

Images