JP4955694B2 - Ｉｐマルチメディアサブシステムにおけるメッセージハンドリング - Google Patents

Description

本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）におけるセッション開始プロトコルのメッセージハンドリング（handling：取り扱い）に関し、特に、必須ではないが、ＩＭＳ内のサービング（serving：在圏）呼／セッション制御機能のコール（呼）フォワーディング（call forwarding：自動転送）に関連するセッション開始プロトコルメッセージのハンドリングのための方法および装置に関するものである。

ＩＰマルチメディアサービスは、同一セッション内の音声、ビデオ、メッセージング、データ等の動的な組み合わせを提供する。組み合わせることが可能な基本アプリケーション数およびメディア数の増加によって、エンドユーザに提供されるサービス数は増大し、個人間通信の経験は豊かになるだろう。このことは、以下でより詳細に検討する、いわゆる「複合ＩＰマルチメディア」サービスを含む、個人向けの豊かなマルチメディア通信サービスの新世代を導くことになるだろう。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって規定された技術であり、これは、移動通信ネットワーク上でＩＰマルチメディアサービスを提供する（３ＧＰＰ ＴＳ ２２．２２８、ＴＳ ２３．２１８、ＴＳ ２３．２２８、ＴＳ ２４．２２８、ＴＳ ２４．２２９、ＴＳ ２９．２２８、ＴＳ ２９．２２９、ＴＳ ２９．３２８およびＴＳ ２９．３２９ リリース５〜７）。ＩＭＳは、標準化ＩＭＳサービスイネーブラの使用を通じて、エンドユーザの個人対個人の通信経験を豊かにするために重要な機能を提供する。ＩＭＳサービスイネーブラは、ＩＰベースのネットワーク上で、新規の豊かな個人対個人（クライアント・ツー・クライアント）通信サービスおよび個人対コンテンツ（クライアント・ツー・サーバ）サービスを容易にする。ＩＭＳは、ユーザ端末間（またはユーザ端末とアプリケーションサーバとの間）の呼またはセッションをセットアップおよび制御するために、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）を使用する。ＳＩＰシグナリングにより搬送されるセッション記述プロトコル（ＳＤＰ：Session Description Protocol）は、セッションのメディアコンポーネントを記述し、かつネゴシエートするために使用される。ＳＩＰがユーザ対ユーザのプロトコルとして生成されているのに対して、ＩＭＳは、オペレータおよびサービスプロバイダがサービスへのユーザアクセスを制御し、それに応じて加入者に課金することを可能にする。

図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合に、移動ネットワークアーキテクチャにＩＭＳがどのように適合するかを概略的に示している。呼／セッション制御機能（ＣＳＣＦ：Call/Session Control Function）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを規定している。これらの内、プロキシ（Ｐｒｏｘｙ） ＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＳＩＰ端末に対するＩＭＳ内の第１の接点である。サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）は、ユーザにユーザが加入しているサービスを提供する。尋問（Ｉｎｔｅｒｒｏｇａｔｉｎｇ） ＣＳＣＦ（Ｉ−ＣＳＣＦ）の役割は、正規のＳ−ＣＳＣＦを識別し、そのＳ−ＣＳＣＦにＰ−ＣＳＣＦを介してＳＩＰ端末から受信した要求を転送することである。

ユーザは、規定のＳＩＰ ＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳに参加し、ＳＩＰユーザアイデンティティに到達できるアドレスをＩＭＳに通知するメカニズムである。ユーザは、ダイアログを開始する場合に、使用する固有のＵＲＩをＳ−ＣＳＣＦから受信する。３ＧＰＰでは、ＳＩＰ端末が登録を実行する場合、ＩＭＳはユーザを認証し、そのユーザに利用可能なＳ−ＣＳＣＦのセットの中から１つのＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰでは規定されていないが、これには、負荷分散およびサービス要件を含んでも良い。Ｓ−ＣＳＣＦの割当は、ＩＭＳベースのサービスへのユーザアクセスを制御（および課金）するために重要であることに注意されたい。オペレータは、直接のユーザ対加ユーザＳＩＰセッションを防ぐメカニズムを提供してもよく、そうしないと直接のユーザ対ユーザＳＩＰセッションは、Ｓ−ＣＳＣＦを回避することになる。

Ｓ−ＣＳＣＦがまだ選択されていない場合、登録プロセス中に、Ｓ−ＣＳＣＦを選択することはＩ−ＣＳＣＦの担当となる。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）から必要なＳ−ＣＳＣＦ機能を受信し、その受信した機能に基づいて適切なＳ−ＣＳＣＦを選択する。［Ｓ−ＣＳＣＦ割当は、ユーザが別のパーティからの呼を受け、加入者がＳ−ＣＳＣＦを現在割り当てられていない場合に、その加入者に対しても、Ｉ−ＣＳＣＦによって実行されることに注意されたい。］登録されたユーザが引き続きセッション要求（例えば、ＳＩＰ ＩＮＶＩＴＥ）をＩＭＳに送信する場合、その要求は、Ｐ−ＣＳＣＦのＵＲＩおよびＳ−ＣＳＣＦ ＵＲＩを含むことになるので、Ｐ−ＣＳＣＦは、その要求を選択されているＳ−ＣＳＣＦに転送することができる。これは、（ＩＭＳの）発信側と着信側の両方に適用される。［着信呼に対しては、その要求は、Ｐ−ＣＳＣＦアドレスおよびＵＥアドレスを含むことになる。］
ＩＭＳサービスネットワーク内には、ＩＭＳサービス機能を実現するために、アプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザにサービスを提供し、３ＧＰＰが規定するＭｒインタフェースを通じて端点として接続されても良いし、または、３ＧＰＰ規定のＩＳＣインタフェースを通じてＳ−ＣＳＣＦによって「リンクイン（liked in）」されても良い。後者の場合には、ＳＩＰセッション確立中、どのアプリケーションサーバが「リンクイン」されるべきかを決定するために、初期フィルタ基準（ＩＦＣ：Initial Filter Criteria）がＳ−ＣＳＣＦによって使用される。このＩＦＣは、ユーザのユーザプロファイルの一部としてＩＭＳ登録手順中、ＨＳＳからＳ−ＣＳＣＦによって受信される。ある種のアプリケーションサーバは、加入者アイデンティティ（着信加入者かまたは発信加入者のアイデンティティで、アプリケーションサーバを制御するネットワークによって「所有される」方である）に依存して動作を実行する。例えば、コールフォワーディングの場合は、適切な（着信）アプリケーションサーバは、所与の加入者への呼を転送することになる新しい着信先を判定することになる。

ＥＴＳＩ ＴＩＳＰＡＮとして知られるワーキンググループが、固定ブロードバンドアクセスに対するＩＭＳの使用を開発している。彼らのタスクの１つは、３ＧＰＰによって規定されるＩＭＳに基づいて、付加サービスを開発することである。これらの付加サービスは、ＴＳ ２４．２２９等の中核の仕様書に影響を及ぼすことになるが、個別の仕様書で定義されることになる。図２は、ＴＳ ２４．２２９（チャプタ５．４．３．２）に従う、ＳＩＰ ＩＮＶＩＴＥに対するＩＭＳ内の発呼側のメッセージフローを概略的に示している。ステップ１）で、ＩＮＶＩＴＥが、発信ユーザ装置（ＵＥ：User Equipment）からＰ−ＣＳＣＦに送信される。このＩＮＶＩＴＥは、そのヘッダにいわゆるＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙを含むとともに、ＳＩＰルートヘッダの最上位レベルにＰ−ＣＳＣＦのＵＲＩおよび第２のエントリとしてＳ−ＣＳＣＦのＵＲＩを含んでいる。このＵＥは、Ｒｅｑｕｅｓｔ−ＵＲＩに、通信相手のアイデンティティも含めている。ＩＮＶＩＴＥの受信時、Ｐ−ＣＳＣＦは、発信ＵＥがＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙとして含まれるアイデンティティを使用することが許可されているかをチェックし、許可されている場合、発信するＩＮＶＩＴＥにＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙとしてそれを含める。このＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙは、認証済のＳＩＰエンティティ間、典型的には、中間エンティティ間で使用されるアインデンティであり、これは、認証によって検証されているので、ＳＩＰメッセージを送信するユーザのアイデンティティを搬送するためのものとなる。このＰ−ＣＳＣＦは、ルートヘッダを調べることによって、発信ＵＥに割り当てられているＳ−ＣＳＣＦを識別し、ステップ２）で、修正されているＩＮＶＩＴＥをそのＳ−ＣＳＣＦに転送する。

Ｓ−ＣＳＣＦは、発呼手順に従って呼を取り扱う（ハンドルする）。Ｓ−ＣＳＣＦは、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを使用して、関係する制約が発信ＵＥに課されているかどうか、例えば、ＵＥが要求されているサービスの使用を禁じられているかどうかをチェックする。Ｓ−ＣＳＣＦは、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙおよび呼の場合も使用して、ＵＥに対するＩＦＣを判定する。図２の例では、Ｓ−ＣＳＣＦが特定のＡＳにＩＮＶＩＴＥを転送する（ステップ３）ことを、ＩＦＣが要求すると想定する。Ｓ−ＣＳＣＦは、ＳＩＰルートヘッダの最上位レベルにＡＳのＵＲＩを含める。Ｓ−ＣＳＣＦは、次のレベルにオリジナルダイアログ識別子（ＯＤＩ：Original Dialog Identifier）と一緒に自身のＵＲＩも含める。ＯＤＩは、Ｓ−ＣＳＣＦによって生成され、Ｓ−ＣＳＣＦへの呼を一意に識別する。ＡＳ自体が、メッセージ（発信の場合）に収容されるＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙに基づいて認証を実行することになる。適切な場合は、Ｓ−ＣＳＣＦによって（例えば、メッセージをＡＳの適切なポートに送信することによって）ＡＳに明らかになる。ＡＳがＩＮＶＩＴＥをＳ−ＣＳＣＦに返信すると（ステップ４）、ＡＳは、ＯＤＩタグとともにＳ−ＣＳＣＦのＵＲＩを残して、ルートヘッダからＡＳのＵＲＩを取り去る。このＯＤＩタグは、Ｓ−ＣＳＣＦに、ＩＮＶＩＴＥが先行するダイアログに関連すると判定することを可能にする。

ＡＳロジックに対しては、新規のセッションのセットアップを要求することが可能であり、その場合、ＡＳに、オリジナルのＲ−ＵＲＩを新規の着信ユーザのＵＲＩで置換することを可能にするメカニズムを提供することが必要となるであろう（既存のＴＳは、このリルーティングシナリオをまだ提供していない）。この場合、元のアイデンティティ、すなわち、ステップ４）のＩＮＶＩＴＥのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙは、発信ＵＥのアイデンティティ、ＡＳのアイデンティティ、またはＡＳが代わって新規のセッションを設定しているサードパーティのアイデンティティのいずれかになり得る。この場合、発信の場合が使用されると想定すると、Ｓ−ＣＳＣＦは、呼制限チェックを繰り返して、「新規の」ＩＮＶＩＴＥに収容されているＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙに基づいてＩＦＣを判定することになる。しかしながら、着信の場合が使用されると、ＡＳがＳ−ＣＳＣＦに信号を送り得ることが考えられ、その場合、チェックは、ＩＮＶＩＴＥのＲ−ＵＲＩを使用して実行される。ＩＦＣに基づくこれ以上のＡＳのリンクインはないと想定すると、Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥに収容されているＲｅｑｕｅｓｔ−ＵＲＩ（Ｒ−ＵＲＩ）ＩＮＶＩＴＥを転送する。これは、オリジナルのＩＮＶＩＴＥに収容されているＲ−ＵＲＩであってもよいし、Ｒ−ＵＲＩが異なる場合は、新規のＩＮＶＩＴＥに収容されている新規のＲ−ＵＲＩであってもよい。

図３は、ＳＩＰ ＩＮＶＩＴＥに対して着呼側のＩＭＳ内のメッセージフローを概略的に示している（ＴＳ ２４．２２９のチャプタ５．４．３．３）。ステップ１）で、被呼者を示すＲ−ＵＲＩを含むＩＮＶＩＴＥが、Ｉ−ＣＳＣＦ（不図示）から到来する。Ｓ−ＣＳＣＦは、被呼者に課されている制約をチェックし、かつＩＦＣを取得するために、このＲ−ＵＲＩを使用する。この場合、ＩＦＣは、ＡＳに連絡する必要があることは示さない。Ｓ−ＣＳＣＦは、Ｒ−ＵＲＩに基づいて、被呼者に対するプレロードされている（preloaded）ルートヘッダを取得し、これらのルートヘッダエントリに基づいて、ＵＥに転送されるＩＮＶＩＴＥを送信することになる。ＩＮＶＩＴＥは、Ｓ−ＣＳＣＦのプレロードされているルートに従って、Ｐ−ＣＳＣＦによって受信され、Ｐ−ＣＳＣＦは、コンタクトヘッダに従ってＵＥにＩＮＶＩＴＥを送信する。

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

１）ＩＮＶＩＴＥが、ＵＥ−Ｆ（Ｒ−ＵＲＩ）にアドレス指定されているＵＥ−Ｏから送信される。Ｓ−ＣＳＣＦ Ｏは、図２を参照して説明される発信側呼手順を実行する。

２）ＡＳ−Ｏとの相互作用後（この段階では、Ｒ−ＵＲＩは変更されていない）、Ｓ−ＣＳＣＦ Ｏは、ＩＮＶＩＴＥをＵＥ−ＦのホームネットワークのＩ−ＣＳＣＦ（不図示）に送信する。Ｉ−ＣＳＣＦは、ＨＳＳからＵＥ−Ｆが登録されているＳ−ＣＳＣＦのアドレスを取得する。ＩＮＶＩＴＥは、そのＳ−ＣＳＣＦ、すなわち、Ｓ−ＣＳＣＦ Ｆに送信される。Ｓ−ＣＳＣＦ Ｆは、制約要件をチェックし、（着信側の場合に対して）図３を参照して上述したように、すなわち、ＩＮＶＩＴＥに収容されているＲ−ＵＲＩに基づきＩＦＣを取得する。図４で示されるシナリオでは、ＩＮＶＩＴＥは、コールフォワーディングがアクティベートされているＡＳ−Ｆに送信される。

３）ＡＳ−Ｆは、Ｒ−ＵＲＩに基づいてプロセス（手順）を認可する（着信の場合を想定）。

４）次いで、ＡＳ−Ｆは、ＩＮＶＩＴＥヘッダのＲ−ＵＲＩを、ＵＥ−ＦのＲ−ＵＲＩからＵＥ−ＴのＲ−ＵＲＩに変更する。変更されたＩＮＶＩＴＥは、Ｓ−ＣＳＣＦ Ｆに返信される。

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

６）Ｓ−ＣＳＣＦ Ｔは、ＩＮＶＩＴＥに収容されているＲ−ＵＲＩ（ＵＥ−ＴのＲ−ＵＲＩ）に基づいて、図３を参照して上述した着信手順を実行する。

再度、図４を参照すると、ステップ５）において、Ｓ−ＣＳＣＦ Ｆに対しては、転送ユーザであるＵＥ−Ｆに何らかの制約が存在するかどうかをチェックすることも、さらに必要となる。これを実行するために、Ｓ−ＣＳＣＦは、典型的には、図２の発信側手順を使用することになる。しかしながら、ＡＳ−Ｆによって実現される特別の手順が存在しないので、ＡＳ−ＦによってＳ−ＣＳＣＦ Ｆに返信されるＩＮＶＩＴＥは、Ｐ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙフィールドにＵＥ−Ｏのアイデンティティを含むことになる。Ｓ−ＣＳＣＦ ＦがＰ−Ａｓｓｅｒｔｅｄ Ｉｄｅｎｔｉｔｙを使用してＩＮＶＩＴＥの発信側チェックを実行することになっていた場合、Ｓ−ＣＳＣＦ Ｆは、それがＳ−ＣＳＣＦ Ｆに「属して」いないので（正確に言えば、Ｓ−ＣＳＣＦ Ｏに属する）、このアイデンティティに対するレコードの所在を突き止めることができない。

この問題の解決策は、ＡＳ−Ｆに対して、ＵＥ−ＯのＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙをＵＥ−ＦのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙで置換することかもしれない。しかしながら、このことは、Ｐ−Ａｓｓｅｒｔｅｄ Ｉｄｅｎｔｉｔｙを端から端まで変更されていないことを要望するオペレータには受け入れられそうにない。オペレータの観点からは、Ｐ−Ａｓｓｅｒｔｅｄ Ｉｄｅｎｔｉｔｙフィールドは、伝統的な（ＰＳＴＮ）発信者アイデンティティと同種である。それゆえ、この問題に対する他の解決策を探究する必要がある。

コールフォワーディングシナリオでは、転送ユーザは、典型的には、発信ユーザと見なされるが、そうである必要はなく、着信ユーザと見なされても良い。この場合、Ｓ−ＣＳＣＦ Ｆは、ＡＳ−ＦからＩＮＶＩＴＥを受信すると、ＩＮＶＩＴＥの着信側チェックの実行を要望する（ＡＳ−ＦからＳ−ＣＳＣＦに送信されるメッセージは、そのメッセージが着信の場合に従って取り扱われるか、それとも発信の場合に従って取り扱われるかをＳ−ＣＳＣＦに示すパラメータを収容する）。しかしながら、このチェックも失敗することになる。それは、ＩＮＶＩＴＥに収容されているＲ−ＵＲＩは、ＵＥ−Ｔを識別し、そのＲ−ＵＲＩが、Ｓ−ＣＳＣＦ ＦではなくてＳ−ＣＳＣＦ Ｔに属するからである。Ｐ−Ａｓｓｅｒｔｅｄ Ｉｄｅｎｔｉｔｙの変更は、当然ながらこの問題に取り組まない。

この問題は、ＩＮＶＩＴＥ以外の、例えば、他の初期要求メッセージおよびスタンドアロンメッセージを含むメッセージでも生じる。

ＳＩＰメッセージ内に収容されているＰ−Ａｓｓｅｒｔｅｄ Ｉｄｅｎｔｉｔｙを変更する必要性を回避しながら、上述の識別されている課題を解消することが本発明の目的である。この目的および他の目的は、アプリケーションサーバに転送する前に、Ｓ−ＣＳＣＦによってサービスを受けるユーザで、かつメッセージに関連するユーザのＵＲＩを収容する新規のヘッダを、Ｓ−ＣＳＣＦにおいて、ＳＩＰメッセージに導入することにより達成される。

本発明の第１の構成に従えば、ＩＰマルチメディアサブシステム内でセッション開始プロトコル通信を取り扱う方法が提供される。この方法は、
メッセージのＲ−ＵＲＩによって識別されるユーザにサービスを提供するサービング呼／状態制御機能（Serving Call/State Control Function）において、セッション開始プロトコルメッセージを受信する工程と、
サービング呼／状態制御機能において、メッセージに、サービング呼／状態制御機能によってサービスが提供されるユーザのＵＲＩを明示的に識別する追加（further）ヘッダを追加する工程と、
メッセージをアプリケーションサーバに転送する工程と、
アプリケーションサーバにおいて、その追加ヘッダで識別されるユーザに対して定義される基準に基づきメッセージを取り扱う工程と、
を備える。

アプリケーションサーバにおいて、メッセージを取り扱う工程は、メッセージのＲ−ＵＲＩをメッセージがリルートされる（reroute：別の経路に切り替られる）ユーザのＵＲＩへの変更すること、およびそのメッセージをサービング呼／状態制御機能に返信することを有してもよい。

前述のメッセージは、Ｓ−ＣＳＣＦによって前述のアプリケーションサーバに直接転送されてもよいし、また、Ｓ−ＣＳＣＦと１つ以上の他のアプリケーションサーバとの間でのメッセージの交換に続いて転送されてもよい。先行する交換では、メッセージヘッダに変更をもたらしてもよい。

前述の追加ヘッダで識別されるユーザに対して定義される基準に基づきメッセージを取り扱う工程は、前述の追加ヘッダで識別されるユーザに対するリルーティング基準を取得すること含んでもよい。

好ましくは、本方法は、Ｓ−ＣＳＣＦにおいて、メッセージを受信する工程と、返信されるメッセージに収容されているオリジナルダイアログ識別子に基づきオリジナルのＲ−ＵＲＩを識別する工程と、そのＲ−ＵＲＩに基づきサービスが提供されているユーザに対するＩＦＣを判定する工程とをさらに備える。選択的には、返信されるメッセージが前述の追加ヘッダを収容している場合、Ｓ−ＣＳＣＦは、追加ヘッダで識別されるユーザに基づきＩＦＣを判定してもよい。

本発明は、メッセージのリルーティングを取り扱う任意のプロセス（すなわち、アプリケーションサーバ）にも適用可能であり、特定のアプリケーションには、ＳＩＰコールフォワーディングがある。

前述の追加ヘッダは、Ｓ−ＣＳＣＦとＡＳ（アプリケーションサーバ）の両方によって理解されるヘッダ識別子によって識別される。典型的には、このヘッダは、プレフィックスであり、例えば、「Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙ」がある。

好ましくは、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙは、Ｓ−ＣＳＣＦで最初に受信されるメッセージも、アプリケーションサーバからＳ−ＣＳＣＦに返信されるメッセージにおけるアイデンティティ同一であり、このアイデンティティは、発信ユーザを識別する。

アプリケーションサーバで受信したメッセージを取り扱う工程は、発信ケース（originating case：発信の場合）または着信ケース（terminating case：着信の場合）の１つに従ってメッセージを取り扱うことを備えてもよく、適切なケース（appropriate case：適切な場合）は、アプリケーションサーバでＳ−ＣＳＣＦから受信されるメッセージ、例えば前述の追加ヘッダで識別される。

Ｓ−ＣＳＣＦにおいて、サービスが提供されるユーザを認証する工程は、発信ケースまたは着信ケースの１つに従ってメッセージを取り扱うことを備えてもよく、適切なケースは、アプリケーションサーバからＳ−ＣＳＣＦによって受信されるメッセージで識別される。

本発明の第２の構成に従えば、サービング呼／状態制御機能から受信されるメッセージを取り扱う処理手段を有する、ＩＰマルチメディアサブシステムのセッション開始プロトコルアプリケーションサーバが提供される。その手段は、サービスが提供されるユーザのＵＲＩを収容するメッセージのヘッダに基づきメッセージを取り扱うように構成され、そのヘッダはサービング呼／状態制御機能によって挿入され、かつＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙおよびＲ−ＵＲＩ以外である。

本発明の第３の構成に従えば、ＩＰマルチメディアサブシステムのサービング呼／状態制御機能ノードが提供される。このサービング呼／状態制御機能ノードは、ＳＩＰメッセージを受信し、かつ初期フィルタ基準をそのメッセージに適用し、初期フィルタ基準がアプリケーションサーバへのメッセージの転送を要求する場合、メッセージが関連するサービスが提供されるユーザのアイデンティティを収容する転送されるメッセージに、ヘッダを追加する手段を備える。

本発明の別の構成に従えば、本発明の第１の構成の方法を実行するコンピュータプログラムコードが提供される。

本発明は、特に、例えば、ＩＮＶＩＴＥ等のセッション開始プロトコル初期要求メッセージ、および、例えば、プレゼンスサービス等のスタンドアローンセッション開始プロトコルメッセージに関連するメッセージに適用可能である。

ＩＰマルチメディアサブシステム内での「フォワーディング」シナリオの取り扱いに関する課題について上述している。アプリケーションサーバ（ＡＳ）とＳ−ＣＳＣＦの両方に対して、適切なユーザ、すなわち、Ｓ−ＣＳＣＦによってサービスが提供されるユーザに対する認可、制約要件のチェックおよびＩＦＣの判定のいずれかを可能にするコールフォワーディングを取り扱うメカニズムであって、適度な融通性を保証するために着信の場合と発信の場合の両方を扱うメカニズムを提供できることは望ましい。

これより、ある発信ユーザ（ＵＥ−Ｏ）からＳ−ＣＳＣＦ Ｆに到来するＩＮＶＩＴＥについて検討する。ＩＮＶＩＴＥは、そのヘッダにＳ−ＣＳＣＦ Ｆの登録ユーザ（ＵＥ−Ｆ）の中の１人を示すＲ−ＵＲＩ、すなわち、ｕｓｅｒｆ＿ｐｕｂｌｉｃ１＠ｈｏｍｅ２．ｎｅｔを含んでいるとする。ＩＮＶＩＴＥは、発信ユーザのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ、すなわち、“Ｊｏｈｎ Ｄｏｅ”＜ｓｉｐ：ｕｓｅｒ１＿ｐｕｂｌｉｃ１＠ｈｏｍｅ１．ｎｅｔ＞、＜ｔｅｌ：＋１−２１２−５５５−１１１１＞も含んでいる。Ｓ−ＣＳＣＦは、着信の場合を使用して、このメッセージを取り扱い（メッセージ内に特別な指示がない場合、特定のポート番号で受信されるメッセージで識別される）、それゆえ、メッセージのＲ−ＵＲＩに基づいて適切なＩＦＣを取得することになる。これらのＩＦＣの中の１つは、メッセージがアプリケーションサーバに転送されるべきであるとことを指示することになる。

メッセージがアプリケーションサーバに転送されるべきと判定する際には、Ｓ−ＣＳＣＦは、追加ヘッダをＩＮＶＩＴＥに追加する。このヘッダは、本明細書では、「Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙ」と呼び、Ｓ−ＣＳＣＦによってサービスが提供され、かつ知識を有しているユーザのアイデンティティである、ＳＩＰ−ＵＲＩまたはＴＥＬ ＵＲＬを収容する。ヘッダは、アプリケーションサーバによって適用されるべき呼の場合も収容する。ヘッダ例は以下の通りである。

Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙ：ｓｉｐ：ａｌｉｃｅ＠ｈｏｍｅ１．ｎｅｔ；ｏｒｉｇ
Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙ：ｓｉｐ：ｂｏｂ＠ｈｏｍｅ２．ｎｅｔ；ｔｅｒｍｕｎｒｅｇ
Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙ：ｓｉｐ：ｂｏｂ＠ｈｏｍｅ２．ｎｅｔ；ｔｅｒｍｒｅｇ
典型的には、コールフォワーディングの場合、発信の場合が適用されることになる。Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙヘッダは、メッセージが転送されるアプリケーションサーバにかかわらず、常にメッセージに追加される。

Ｓ−ＣＳＣＦは、ルートヘッダの最上位ＵＲＩとして、ＡＳのＳＩＰ ＵＲＩ、すなわち、ｓｉｐ：ａｓ１．ｈｏｍｅ１．ｎｅｔ；ｌｒを追加し、「オリジナルダイアログ識別子」（ＯＤＩ）と一緒にルートヘッダのＡＳ ＵＲＩの下に自身のＳＩＰ ＵＲＩを含める標準的な動作も実行する。その結果生じる例示のＩＮＶＩＴＥメッセージ構造を図５に示す。ここでは、ルートヘッダに追加されるＳ−ＣＳＣＦ ＦのＵＲＩは、「ｓｃｓｃｆ１．ｈｏｍｅ１．ｎｅｔ；ｌｒ」であり、また、ＯＤＩは「ｃｂ０３ａ０ｓ０９ａ２ｓｄｆｇｌｋｊ４９０３３３」である。次いで、メッセージは、ＩＳＣインタフェースを通じてアプリケーションサーバに転送される。Ｓ−ＣＳＣＦ Ｆは、ＩＮＶＩＴＥが関連するセッションに対する状態情報を維持する。この情報は、ＯＤＩおよびサービスが提供されるユーザＦのアイデンティティを含んでいる。

Ｓ−ＣＳＣＦからのＩＮＶＩＴＥメッセージの受信時、アプリケーションサーバは、常に、メッセージで識別される（発信または着信）の場合に従って、Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙに基づく認可を実行する。コールフォワーディングが実行される場合、ＩＮＶＩＴＥに収容されるＲ−ＵＲＩに基づき、アプリケーションサーバは、オリジナルのＲ−ＵＲＩを、呼が転送されるユーザ（ＵＥ−Ｔ）のＵＲＩで置換することになる。加えて、アプリケーションサーバは、ＩＮＶＩＴＥが発呼型の手順を使用して取り扱われることを示すために、「ｏｒｉｇ」パラメータをルートヘッダに追加することになる。最上位ルーティングヘッダ、すなわち、アプリケーションサーバのＵＲＩは、メッセージから取り去られ、そして、そのメッセージは、Ｓ−ＣＳＣＦに返信される。返信されるメッセージは、Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙヘッダを保持する。

Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙヘッダを収容するメッセージを受信する場合のＳ−ＣＳＣＦのデフォルト動作は、受信メッセージのＯＤＩに対応するセッション状態情報に収容される、サービスが提供されるユーザに基づいて、ＩＦＣチェックを実行することである。（Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙヘッダに収容されているユーザアイデンティティは、この目的のために使用できるが、できるだけ既存の手順の変更を回避することが好ましい）。Ｓ−ＣＳＣＦは、ルートヘッダで識別される場合に応じて（または、ＩＮＶＩＴＥをＡＳから受信するポート番号に基づき）、着信の場合または発信の場合を適用することになる。典型的には、転送されるＩＮＶＩＴＥは、発呼型に従って取り扱われる（この例では、Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙヘッダに収容されている場合は、Ｓ−ＣＳＣＦで使用することは可能ではあるが、Ｓ−ＣＳＣＦによっては使用されない）。

ＩＳＣを通じて受信されるメッセージにＯＤＩがない場合、Ｓ−ＣＳＣＦは、Ｐ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙまたはＲ−ＵＲＩに基づき、必要なチェックを実行することになる。

ＩＦＣチェックの完了に続いて、Ｓ−ＣＳＣＦは、識別されるＩＦＣに従ってＩＮＶＩＴＥを処理することになる。これには、着信ユーザＵＥ−Ｔへのメッセージの直接転送を含んでもよいし、あるいは、場合によっては、別のアプリケーションサーバへのメッセージの転送を含んでもよい。

場合によっては、ＩＳＣインタフェースを介するＳＩＰメッセージ（ＩＮＶＩＴＥ）の受信に応じて、Ｓ−ＣＳＣＦで実行されるＩＦＣチェックは、メッセージが別のアプリケーションサーバへ転送されることを要求してもよい。第２のＡＳに転送されるメッセージ例を図７に示す。この場合もやはり、Ｐ−Ｓｅｒｖｅｄ−Ｕｓｅｒ−Ｉｄｅｎｔｉｔｙヘッダは、ユーザＦのＵＲＩ、すなわち、ｕｓｅｒｆ＿ｐｕｂｌｉｃ１＠ｈｏｍｅ２．ｎｅｔを収容するのに対して、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙは、発信ユーザのＵＲＩであり、また、Ｒ−ＵＲＩは、新規の着信ユーザのＵＲＩである。図８は、Ｓ−ＣＳＣＦ Ｆと２つのＡＳサーバであるＡＳ−Ｆ１およびＡＳ−Ｆ２との間のメッセージ交換を示している。

本発明の範囲から逸脱することなく、様々な変更が、上述の実施形態で行ない得ることが当業者には明らかであろう。

ＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合の概略図である。 ＩＭＳの発呼側のＳＩＰ ＩＮＶＩＴＥのフローを示す図である。 ＩＭＳの着呼側のＳＩＰ ＩＮＶＩＴＥのフローを示す図である。 コールフォワーディングシナリオにおけるＩＭＳ内のＳＩＰ ＩＮＶＩＴＥのフローを示す図である。 Ｓ−ＣＳＣＦからアプリケーションサーバに送信されるＳＩＰ ＩＮＶＩＴＥメッセージのメッセージヘッダ構造を示す図である。 アプリケーションサーバからＳ−ＣＳＣＦに送信されるＳＩＰ ＩＮＶＩＴＥメッセージのメッセージヘッダ構造を示す図である。 Ｓ−ＣＳＣＦから第２のアプリケーションサーバに送信されるＳＩＰ ＩＮＶＩＴＥメッセージのメッセージヘッダ構造を示す図である。 図７のメッセージ構造を含むＩＭＳエンティティ間のシグナリング交換を示す図である。

Claims (11)

1. ＩＰマルチメディアサブシステム内でセッション開始プロトコル通信を取り扱う方法であって、
   メッセージのＲ−ＵＲＩによって識別されるユーザにサービスを提供するサービング呼／状態制御機能において、セッション開始プロトコルメッセージを受信する工程と、
   前記サービング呼／状態制御機能において、前記メッセージに、前記サービング呼／状態制御機能によってサービスが提供される前記ユーザの前記ＵＲＩを明示的に識別する追加ヘッダを追加する工程と、
   前記メッセージをアプリケーションサーバに転送する工程と、
   前記アプリケーションサーバにおいて、前記追加ヘッダで識別される前記ユーザに対して定義される基準に基づき前記メッセージを取り扱う工程と
   を備えることを特徴とする方法。
2. 前記アプリケーションサーバにおいて、前記メッセージを取り扱う工程は、前記メッセージの前記Ｒ−ＵＲＩを前記メッセージがリルートされるユーザのＵＲＩへの変更、および前記メッセージをサービング呼／状態制御機能に返信することを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記メッセージは、前記サービング呼／状態制御機能によって前記アプリケーションサーバに直接転送される、または、前記サービング呼／状態制御機能と１つ以上の他のアプリケーションサーバとの間での前記メッセージの交換に続いて転送される
   ことを特徴とする請求項１または２に記載の方法。
4. 前記メッセージを取り扱う工程は、前記追加ヘッダで識別される前記ユーザに対するリルーティング基準を取得することを含む
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記サービング呼／状態制御機能において、前記アプリケーションサーバから前記メッセージを受信する工程と、
   返信される前記メッセージに収容されているオリジナルダイアログ識別子に基づきオリジナルのＲ−ＵＲＩを識別する工程と、
   前記Ｒ−ＵＲＩに基づきサービスが提供されている前記ユーザに対するＩＦＣを判定する工程と
   をさらに備えることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記メッセージを取り扱う工程は、アプリケーションコールフォワーディング手順を実行することを含む
   ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記追加ヘッダは、前記サービング呼／状態制御機能と前記アプリケーションサーバの両方によって理解されるヘッダ識別子によって識別される
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記アプリケーションサーバから前記サービング呼／状態制御機能へ前記メッセージを返信する工程を更に備え、
   Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙは、前記サービング呼／状態制御機能で最初に受信される前記メッセージと、前記アプリケーションサーバから前記サービング呼／状態制御機能に返信される前記メッセージとの両方におけるアイデンティティと同一であり、
   前記Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙは、発信ユーザを識別する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記メッセージを取り扱う工程は、発信の場合または着信の場合の１つに従って前記メッセージを取り扱うことを含み、
   適切な場合は、前記アプリケーションサーバで識別される
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. サービング呼／状態制御機能から受信されるメッセージを取り扱う処理手段を有する、ＩＰマルチメディアサブシステムのセッション開始プロトコルアプリケーションサーバであって、
    前記処理手段は、サービスが提供されるユーザのＵＲＩを収容する前記メッセージのヘッダに基づきメッセージを取り扱うように構成され、
    前記ヘッダは、サービング／呼状態制御機能によって挿入され、かつＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙおよびＲ−ＵＲＩ以外である
    ことを特徴とするセッション開始プロトコルアプリケーションサーバ。
11. ＩＰマルチメディアサブシステムのサービング呼／状態制御機能ノードであって、
    メッセージのＲ−ＵＲＩによって識別されるユーザにサービスを提供する当該サービング呼／状態制御機能において、セッション開始プロトコルメッセージを受信する手段と、
    前記メッセージに、当該サービング呼／状態制御機能によってサービスを提供する前記ユーザの前記ＵＲＩを明示的に識別する追加ヘッダを追加する手段と、
    前記追加ヘッダで識別される前記ユーザに対して定義される基準に基づき前記メッセージをアプリケーションサーバで取り扱わせるために、前記メッセージをアプリケーションサーバに転送する手段と
    を備えることを特徴とするサービング呼／状態制御機能ノード。

Images