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

Description

本発明は、通信ネットワークにおけるセッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）のメッセージハンドリングに関する。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動体通信ネットワーク上でＩＰマルチメディアサービスを提供するために、第３世代パートナーシッププロジェクト（３ＧＰＰ：the Third Generation Partnership Project）により定義された技術である（３ＧＰＰ ＴＳ ２２．２２８）。ＩＭＳは、サービスの統合およびインタラクションを通じて、エンドユーザの個人対個人の通信体験を豊かにする重要な特徴を提供する。ＩＭＳによって、ＩＰベースのネットワーク上における個人対個人（クライアント対クライアント）および個人対コンテンツ（クライアント対サーバ）の新しい豊かな通信が可能となる。

ＩＭＳは、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）を使用して、ユーザ端末（ＵＥ）間、またはＵＥとアプリケーションサーバ（ＡＳ）との間の呼またはセッションを設定し、制御する。ＳＩＰシグナリングで搬送されるセッション記述プロトコル（ＳＤＰ：Session Description Protocol）を使用して、セッションのメディアコンポーネントを記述し、取り決める。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳにより、運用者およびサービスプロバイダは、サービスへのユーザアクセスを制御し、それに応じてユーザに課金することができる。

ＩＭＳネットワークでは、呼セッション制御機能（ＣＳＣＦ：Call/Session Control Functions）が、ＩＭＳ内のＳＩＰエンティティとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを定義している：ＳＩＰ端末にとってＩＭＳ内の最初の接点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）；ユーザに対して、当該ユーザが加入しているサービスを提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）；正しいＳ−ＣＳＣＦを識別し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受け取った要求を当該Ｓ−ＣＳＣＦに転送する役割を持つ問い合わせ（Interrogating）ＣＳＣＦ（Ｉ−ＣＳＣＦ）；である。

ＩＭＳのサービス機能は、アプリケーションサーバ（ＡＳ）を使用して実装される。任意のＵＥについて、１つ以上のＡＳが当該端末に関連付けられる。ＡＳは、ＩＭＳサービス制御（ＩＳＣ）インターフェースを介してＳ−ＣＳＣＦと通信し、要求に応じて（例えば、所定のＵＥのためにＳ−ＣＳＣＦにダウンロードされるｉＦＣのトリガリング（triggering）の結果として）、ＳＩＰメッセージルートに接続される。

ユーザは、特定されたＳＩＰのＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳに所属し、ＳＩＰユーザＩＤが到達され得る位置を与えるアドレスを、ＩＭＳに知らせるためのメカニズムである。３ＧＰＰでは、ＳＩＰ端末が、登録を行った場合に、ＩＭＳは、ホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）に保存された加入（subscription）情報を使用してユーザを認証し、利用できるＳ−ＣＳＣＦのセットから当該ユーザにＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は、３ＧＰＰにより仕様化されていないが、これらの基準は、負荷分散およびサービス要件を含み得る。Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスへのユーザアクセスの制御および課金の手段であることに留意する。運用者は、他の方法でＳ−ＣＳＣＦを迂回するユーザ対ユーザの直接のＳＩＰセッションを防ぐためのメカニズムを提供し得る。

登録過程の中で、Ｓ−ＣＳＣＦがまだ選択されていない場合に、Ｓ−ＣＳＣＦを選択することは、Ｉ−ＣＳＣＦの責任である。Ｉ−ＣＳＣＦは、要求されるＳ−ＣＳＣＦのケイパビリティをＨＳＳから受信し、受信したケイパビリティに基づいて適当なＳ−ＣＳＣＦを選択する。ユーザが、別の当事者から発呼され、ユーザには、現在Ｓ−ＣＳＣＦが割り当てられていない場合にも、Ｓ−ＣＳＣＦの割り当ては、Ｉ−ＣＳＣＦによって、ユーザのために実施されることに留意する。登録されたユーザが、その後ＩＭＳにセッション要求を送信する場合、Ｐ−ＣＳＣＦは、登録過程の中でＳ−ＣＳＣＦから受け取った情報に基づいて、選択されたＳ−ＣＳＣＦに要求を転送することができる。

各ＩＭＳユーザは、１つ以上のプライベートユーザＩＤを保有する。プライベートユーザＩＤは、ホームネットワークの運用者により割り当てられ、例えば、登録、許可、管理および課金の目的で、ＩＭＳにより使用される。このＩＤは、ＩＥＴＦ ＲＦＣ ２４８６にて定義されているように、ネットワークアクセス識別子（ＮＡＩ）の形をとる。国際移動体加入者識別番号（ＩＭＳＩ：International Mobile Subscriber Identity）の表現が、プライベートＩＤのためのＮＡＩの中に含まれることは可能である。３ＧＰＰ ＴＳ ２３．２２８は、以下のようなプライベートユーザＩＤの特性を仕様化している：
・プライベートユーザＩＤは、ＳＩＰメッセージのルーティングには使用されない。
・プライベートユーザＩＤは、ＵＥからホームネットワークに送信される全ての登録要求（再登録および登録抹消の要求を含む）に含まれる。
・ＩＰマルチメディアサービスＩＤモジュール（ＩＳＩＭ：IP multimedia Services Identity Module）アプリケーションは、１つのプライベートユーザＩＤを安全に保存する。ＵＥが、ＩＳＩＭアプリケーション上に保存されたプライベートユーザＩＤの情報を修正することはできない。
・プライベートユーザＩＤは、ホームネットワークの運用者により定義されたユニークなグローバルＩＤであり、ホームネットワーク内で使用して、ネットワークの観点からユーザの加入（例えば、ＩＭサービスのケイパビリティ）を識別し得る。プライベートユーザＩＤは、ユーザではなく、加入を識別する。
・プライベートユーザＩＤは、ユーザの加入に恒久的に割り当てられ（動的なＩＤではない）、ホームネットワークでのユーザの加入の期間内は有効である。
・プライベートユーザＩＤを使用して、ＨＳＳに保存されたユーザ情報（例えば、認証情報）を識別する（例えば、登録の間に使用するため）。
・プライベートユーザＩＤは、運用者のポリシーに基づく課金記録の中に存在し得る。
・プライベートユーザＩＤは、ユーザの登録（再登録および登録抹消を含む）の間にのみ認証される。
・登録および登録抹消される終了においてプライベートユーザＩＤを取得し、および保存するために、Ｓ−ＣＳＣＦが必要である。

プライベートユーザＩＤに加えて、各ＩＭＳユーザは、１つ以上のＩＭＳパブリックユーザＩＤ（ＰＵＩ）を持つ。ユーザがＰＵＩを使用して、他のユーザへの通信を要求する。ユーザは、例えば名刺上にＰＵＩ（しかし、プライベートユーザＩＤではない）を含め得る。３ＧＰＰ ＴＳ ２３．２２８は、以下のようなＰＵＩの特性を仕様化している：
・電話のナンバリングおよびインターネットのネーミングスキームの双方が、ユーザが持つＰＵＩ次第で、ユーザのアドレスを指定するために使用され得る。
・ＰＵＩは、ＲＦＣ３２６１およびＲＦＣ２３９６にて定義されるとおりＳＩＰ ＵＲＩの形、またはＲＦＣ３９６６にて定義される“ｔｅｌ：”ＵＲＩ形式をとる。
・ＩＳＩＭアプリケーションは、少なくとも１つのＰＵＩを安全に保存するが（ＵＥがＰＵＩを修正できるべきではない）、追加のＰＵＩ全てをＩＳＩＭアプリケーション上に保存することは求められない。
・ＰＵＩを使用してＩＭＳセッションおよびＩＭＳセッションに関連しない手続きを開始することができる前に、ＰＵＩは、明示的にまたは暗黙的に登録される。
・ＩＭＳセッションの終了またはＩＭＳセッションに関連しない手続きの終了が、ＰＵＩが属するユーザのＵＥに伝えられることができる前に、ＰＵＩは、明示的にまたは暗黙的に登録される。
・ＩＭＳ内のメカニズムを介して（例えば、暗黙的登録セットを使うことにより）１つより多いＰＵＩを持つユーザをグローバルに登録するができる（例えば、単一のＵＥの要求を通じて）。これは、ユーザが、必要であれば複数のＰＵＩを個別に登録することを妨げない。
・ＰＵＩは、登録の間はネットワークによって認証されない。
・ＰＵＩを使用して、ＨＳＳ内のユーザ情報を識別し得る（例えば、移動体終端セッションの設定の間）。
・ＩＭＳ内のＡＳがＰＵＩを使用して、ユーザに適用されるサービスの設定データを識別し得る。

図１は、ユーザ（ＩＭＳ）の加入と、パブリックユーザＩＤおよびプライベートユーザＩＤとの間の関係の例を概略的に説明している。示されている例で、加入者は、２つのプライベートユーザＩＤを持ち、両方のＩＤは、２つのパブリックユーザＩＤに関連付けられている（パブリックユーザＩＤのうちの１つであるパブリックユーザＩＤ−２は、両方のプライベートユーザＩＤに関連付けられている）。サービスプロファイルは、各パブリックユーザＩＤと関連付けられており、このプロファイルは、関連付けられるパブリックユーザＩＤのためのサービスデータを特定するものである。アプリケーションサーバが、ホーム加入者サーバのユーザのために設定される場合に、サービスプロファイルは、作成され、または修正される。各サービスプロファイルは、１つ以上の初期フィルタ基準（ｉＦＣ：initial Filter Criteria）を含み、ｉＦＣを使用して、ＩＭＳサービスの提供または制限をトリガリングする（trigger）。サービスプロファイル−１およびサービスプロファイル−２により提供されるサービス間の違いは、運用者によって個別であるが、異なるアプリケーションサーバ（ＡＳ）、さらに異なる課金／レーティングのスキームを含み得る。

図１に示される例では、パブリックユーザＩＤ−１は、サービスプロファイル−１に関連付けられ、一方でパブリックユーザＩＤ−２およびパブリックユーザＩＤ−３は、サービスプロファイル−２に関連付けられている。典型的なシナリオでは、パブリックユーザＩＤ−１は、例えば"Big_Joe@priv.operator.com"のように、ユーザが友人および家族に渡すＩＤであり、一方でパブリックユーザＩＤ−２およびパブリックユーザＩＤ−３は、例えば"+46111222333@operator.com"および"joe.black@operator.com"のように、ユーザがビジネスの連絡に割り当てるＩＤであるかもしれない。

３ＧＰＰは、いわゆる「暗黙的登録セット（Implicit Registration Set）」の概念を定義して、グループとして機能するＰＵＩのセットを識別する。上記ＰＵＩのセットは、ＰＵＩのセットのうちの任意の１つが登録され、または登録抹消される場合に、共に登録され、および登録抹消される。３ＧＰＰは、ＨＳＳが、ユーザの登録または呼の終了においてＳ−ＣＳＣＦに暗黙的登録セットを送信するように、要求する。登録では、ＨＳＳは、暗黙的登録セット内の全てのＰＵＩを識別し、次にこれらのＰＵＩと関連付けられる全てのサービスプロファイルを識別することは、理解されている。サービスプロファイルと関連付けられるＰＵＩを含むサービスプロファイル（またはサービスプロファイルから選択されたデータ）は、次にＳ−ＣＳＣＦに送信される。この動作の結果として、Ｓ−ＣＳＣＦは、同じ暗黙的登録セットに属する全てのＰＵＩ、およびそれらのサービスプロファイルを知る。

可能性のあるＩＭＳの使用事例には、ユーザの集まりが、ＩＭＳのグループレベルの加入を有するが、個々のユーザ自身は加入を有しておらず、ＩＭＳはそれを知らないことが含まれる。ユーザへの直接的な内外へのダイヤリングを可能とすることが望ましい。これは、例えば、会社が、ＩＭＳへの加入を有し、個々の従業員の事業所または端末をＩＰ構内交換機（ＩＰ−ＰＢＸ）に接続する場合に起こり得る。従業員の端末は、ＳＩＰクライアントと共に提供されるかもしれないし、ＳＩＰクライアントと共には提供されないかもしれない。後者の場合、ＩＰ−ＰＢＸは、ＳＩＰシグナリングとＳＩＰではないシグナリングとの間の変換を実施する。ＩＭＳが、（同じ暗黙的登録セット内における）各端末の個々のＰＵＩを記録することはもちろん可能であり得るが、これは、グループのサイズが大きくなる場合に非効率的となる。ＥＴＳＩ ＴＩＳＰＡＮは、そのような企業ネットワークを次世代企業ネットワークとして定義する。

加入に関連付けられた暗黙的登録セット内に、ワイルドカード化されたパブリックユーザＩＤを含めることができる。「ワイルドカード化された」または「ワイルドカード」は、１つ以上の不特定の文字を表すシンボルを含むパブリックユーザＩＤを意味すると、ここでは理解される。ワイルドカード化されたパブリックユーザＩＤは、それに関連付けられるサービスプロファイルを有する。暗黙的登録セットに基づいてチェックまたは処理を行うＩＰマルチメディアサブシステム内のいずれのノードも、受け取ったパブリックユーザＩＤが暗黙的登録セット内の任意の標準的なパブリックユーザＩＤと一致する場合と同様に、ワイルドカード化されたパブリックユーザＩＤと一致する受け取ったパブリックユーザＩＤに基づいて動作する。ワイルドカード化されたパブリックユーザＩＤを使用してパブリックユーザＩＤの範囲を表すよりはむしろ、そのような範囲は、代わりにサブドメインによって表され得る。例えば、ｔｅｌ ＵＲＩの範囲は、ダイヤル局番により表され得るし、一方でＳＩＰ ＵＲＩの範囲は、企業ドメインにより表され得る。これにより、企業ネットワークが、Ｇｍ参照点（Gm reference point）を通ってＩＭＳネットワークに接続される場合に、企業ネットワークのユーザへの、または企業ネットワークのユーザからのルーティングが可能となる。

しかしながら、ＴＩＳＰＡＮが公開するビジネスコミュニケーション要件（ＥＴＳＩ ＴＳ １８１ ０１９（Ｖ２．０．０）：Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN)；Business Communication Requirements）には、運用者の信頼できるドメインは、ＩＭＳネットワークと信頼される企業ネットワークとの間のビジネストランクが整っている企業ネットワークのドメインまで拡張することができるべきだ、と述べられた要求がある。この意味合いは、ＩＭＳネットワークにおけるＰ−ＣＳＣＦが、Ｇｍ参照点を通って企業ネットワークから送信されたＰ−アサーテドＩＤ（P-Asserted-ldentity）ヘッダを受け取らなければならないということである。Ｐ−アサーテドＩＤヘッダは、ＳＩＰ ＵＲＩおよび任意の表示名を含むＳＩＰメッセージのヘッダである。Ｐ−アサーテドＩＤは、認証により証明された場合に、ＳＩＰメッセージを送信するユーザのＩＤを搬送するために、信頼されるＳＩＰエンティティの中で使用されるＩＤであり、典型的な手段である。Ｐ−アサーテドＩＤは、ノードが何らかの方法で発信ユーザを認証すると、ＳＩＰエンティティによりＳＩＰメッセージのヘッダフィールドに挿入される。この結果、Ｐ−アサーテドＩＤが、遠隔ネットワーク／企業ネットワーク／プライベートネットワークにより認証されたＩＤを含んでいるため、Ｐ−アサーテドＩＤは、ＩＭＳネットワークのサービスを受ける発信ユーザを表さない可能性がある。

Ｓ−ＣＳＣＦは、通常、Ｐ−アサーテドＩＤを使用して、何らかの関連する制限が発信ＵＥにかけられているかチェックする。例えば、ＵＥが、要求されるサービスを使用することを禁止されているかどうかである。Ｓ−ＣＳＣＦは、Ｐ−アサーテドＩＤおよび呼の場合を使用して、ＵＥのために初期フィルタ基準（ｉＦＣ）を判定する。例えば、Ｓ−ＣＳＣＦが特定のＡＳへＩＮＶＩＴＥを転送することを、ＩＦＣが求めると仮定すると、Ｓ−ＣＳＣＦはＳＩＰルートヘッダの最上部の位置にＡＳのＵＲＩを含める。Ｓ−ＣＳＣＦは、また、オリジナルダイヤログ識別子（ＯＤＩ：Original Dialog Identifier）と共に、次の位置に自らのＵＲＬを含める。ＯＤＩは、Ｓ−ＣＳＣＦにより生成され、Ｓ−ＣＳＣＦへの呼をユニークに識別する。ＡＳ自身は、メッセージ中に含まれるＰ−アサーテドＩＤに基づいて、認証を行う。発信側のＩＭＳネットワークがユーザに正しいポリシー／サービスを実行できるように、発信側のＩＭＳネットワークにおいてＰ−アサーテドＩＤを使用して、サービスを受けるユーザを判定するということが、ここから結論付けられる。

上記のとおり、信頼するドメインが、公衆のＩＭＳネットワークからＧｍ参照点を通って接続される別のネットワークへ拡張される場合、Ｐ−アサーテドＩＤはＩＭＳネットワークでは知られていないユーザＩＤを含む可能性がある。しかしながら、発信するＩＭＳのコアシステムもＰ−アサーテドＩＤを使用して、サービスを受けるユーザを判定するため、問題が生じる。Ｐ−ＣＳＣＦにより現在サービス提供を受けるユーザを表さない当該ユーザのＰ−アサーテドＩＤを含み、および知られているＩＭＳユーザのＩＤが含まれないＰ−アサーテドＩＤを時として含むメッセージを転送する場合、現在の手続きは失敗し、誤ったユーザに手続きを実行し、またはＰ−ＣＳＣＦは異なるユーザに属するＰ−アサーテドＩＤを送るだろう。

発明者は、ＩＭＳネットワークが、信頼できるドメインを別のネットワークまで拡張できるようにする方法を案出した。ＩＭＳネットワーク中のＰ−ＣＳＣＦは、信頼される企業ドメインからのＳＩＰメッセージを受信した後、ＳＩＰメッセージをＳ−ＣＳＣＦに送信する前に、ＳＩＰメッセージの中にＰ−サーブドユーザヘッダ（P-Served-User header）と呼ばれる新たなヘッダを挿入する。任意に、Ｐ−ＣＳＣＦは、ＳＩＰメッセージの中のＰ−アサーテドＩＤが、信頼されるエンティティに属する暗黙的登録セットのＩＤと一致しない場合にのみ、新たなヘッダを挿入する。Ｐサーブドヘッダは、サービスを提供されるユーザのＩＤを含む。サービスを提供されるユーザのＩＤは、ＳＩＰメッセージがＩＭＳネットワークに入るにあたり通る信頼されるネットワークサイトに属する既定のＩＤである。その後ＳＩＰメッセージ受信するＳ−ＣＳＣＦは、次に、Ｓ−ＣＳＣＦが、サービスを受けるユーザを判定するためにＰ−サーブドユーザヘッダフィールドを使用しなければならないこと、およびサービスを受けるユーザを判定するためにＰアサーテドヘッダフィールドを無視できることを知る。

本発明の第１の形態によると、ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク内でセッション開始プロトコル（ＳＩＰ）の通信をハンドリングする方法が与えられる。プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）は、遠隔ネットワークから送信されるＳＩＰメッセージを受信する。Ｐ−ＣＳＣＦは、ＩＭＳネットワーク内のサービング呼セッション制御機能によりサービス提供される遠隔ネットワーク内の信頼されるエンティティの、パブリックユーザＩＤを識別する追加ヘッダを、メッセージに付け加える。任意に、ＳＩＰメッセージの中のＰ−アサーテドＩＤが、信頼されるエンティティのＩＤと一致しない場合にのみ、Ｐ−ＣＳＣＦは新たなヘッダの挿入を行う。信頼されるエンティティのパブリックユーザＩＤは、メッセージが受信されたセキュアなチャネルのＩＤを判定することにより、任意に取得される。メッセージは、その後Ｓ−ＣＳＣＦに送信される。Ｓ−ＣＳＣＦおよびメッセージが送信される任意の他のノードは、Ｓ−ＣＳＣＦによりサービス提供されるパブリックユーザＩＤであるユーザＩＤを含まないかもしれないＰ−アサーテドＩＤの内容を無視すること、および代わりに追加ヘッダに含まれる信頼されるエンティティのパブリックユーザＩＤを使用することを、追加ヘッダの存在から知る。

ＳＩＰメッセージは、遠隔ネットワークとＩＭＳネットワークとの間のビジネストランクを介して任意に送信され、遠隔ネットワークは、ＩＭＳネットワークにより信頼される。ＩＭＳネットワークのＰ−ＣＳＣＦは、遠隔ネットワークを信頼するため（これは、同じ信頼ドメインにいる、と呼ぶことができる、IETF RFC 3324 and RFC 3325を参照）、そのネットワークから受信したPアサーテドＩＤを信頼し、Ｐ−ＣＳＣＦを信頼するＩＭＳネットワーク内のノードは、Ｐ−ＣＳＣＦ等から受信したＰ−アサーテドＩＤを信頼するだろう。これは推移的信頼（transitive trust）と呼ばれる。ＩＭＳネットワーク内のノードは、その結果、信頼されるエンティティを信頼できることを知る。

任意に、プライベートネットワークのノードを識別する追加ヘッダは、ＩＰマルチメディアサブシステムネットワーク内のホーム加入者サーバ、またはＮＧＮネットワークの場合のユーザプロファイルサーバ機能に保存されている、信頼されるエンティティのパブリックユーザＩＤ関連する加入情報から取得される。

信頼されるエンティティのパブリックユーザＩＤに関連する加入情報は、任意に、暗黙的登録セットを含む。任意に、暗黙的登録セットは、ワイルドカード化されたパブリックユーザＩＤ、またはパブリックユーザＩＤの範囲に関するパブリックユーザＩＤのサブドメイン表現を含む。さらなる選択肢としては、ＳＩＰメッセージは、遠隔ネットワークのユーザの代わりに、信頼されるエンティティから送信されるＳＩＰのＩＮＶＩＴＥメッセージである。

本発明の第２の形態によると、ＩＭＳネットワーク内の使用のためのＰ−ＣＳＣＦノードが与えられる。Ｐ−ＣＳＣＦノードは、遠隔ネットワークから送信されるＳＩＰメッセージを受信するための受信部を有する。処理部は、Ｓ−ＣＳＣＦによりサービス提供される遠隔ネットワーク内の信頼されるエンティティの、パブリックユーザＩＤを識別する追加ヘッダを、メッセージに付け加えるために与えられる。Ｐ−ＣＳＣＦは、また、Ｓ−ＣＳＣＦにメッセージを送信するための送信部を含む。ＩＭＳネットワーク内の他のノードにより追加ヘッダが使用されることで、サービスを提供されるノードを識別するために、Ｐ−アサーテドＩＤヘッダ内に含まれる情報よりはむしろ追加ヘッダ内の情報を使用するように、それらのノードに通知することができる。

Ｐ−ＣＳＣＦは、任意に、ＩＭＳネットワーク内のホーム加入者サーバおよびユーザプロファイルサーバ機能のうちの１つから、信頼されるエンティティのパブリックユーザＩＤに関連する加入情報を受信するための手段を有する。

加入情報は、任意に、ワイルドカード化されたパブリックユーザＩＤ、またはパブリックユーザＩＤの範囲に関するパブリックユーザＩＤのサブドメイン表現を含む、暗黙的登録セットを含む。

本発明の第３の形態によると、ＩＭＳネットワーク内の使用のためのＳ−ＣＳＣＦノードが与えられる。Ｓ−ＣＳＣＦノードは、Ｐ−ＣＳＣＦノードからのセッション開始プロトコルのメッセージを受信するための受信部、およびセッション開始プロトコルのメッセージ内における追加ヘッダの存在を識別するための処理部を有する。上記追加ヘッダは、サービング呼セッション制御機能によりサービスを提供される遠隔ネットワーク内の信頼されるエンティティの、パブリックユーザＩＤを識別する。Ｓ−ＣＳＣＦは、また、追加ヘッダが識別された場合に、ＳＩＰメッセージ内に含まれるＰ−アサーテドＩＤヘッダの代わりに、サービスを受けるユーザを判定するために上記ヘッダ内の信頼されるエンティティのパブリックユーザＩＤを使用するための手段を有する。このように、Ｓ−ＣＳＣＦにより受信された、サービスを受けるユーザがＰ−アサーテドＩＤにより識別されないメッセージは、適切に処理され得る。

本発明の第４の形態によると、ＩＭＳネットワーク内の使用のためのアプリケーションサーバ（ＡＳ）が与えられる。ＡＳは、ＳＩＰメッセージを受信するための受信部、およびセッション開始プロトコルのメッセージ内における追加ヘッダの存在を識別するための処理部を有する。追加ヘッダは、ＩＭＳネットワークにおいて、Ｓ−ＣＳＣＦによりサービスを提供される遠隔ネットワーク内の信頼されるエンティティのパブリックユーザＩＤを識別する。ＡＳは、追加ヘッダが識別された場合に、Ｐ−アサーテドＩＤヘッダの代わりに、サービスを受けるユーザを判定するために上記ヘッダ内の信頼されるエンティティのパブリックユーザＩＤを使用するための手段をさらに有する。

ユーザのＩＭＳ加入と、パブリックユーザＩＤおよびプライベートユーザＩＤとの関係の例を概略的に説明している。 ブロック図にて、本発明の実施形態に従った、企業ネットワークとＩＭＳネットワークとの間のシグナリングフローを概略的に説明している。 本発明の実施形態の基本的なステップを示すフロー図である。 ブロック図にて、本発明の実施形態に従ったＰ−ＣＳＣＦを概略的に説明している。 ブロック図にて、本発明の実施形態に従ったＳ−ＣＳＣＦを概略的に説明している。 ブロック図にて、本発明の実施形態に従ったアプリケーションサーバを概略的に説明している。

図２を参照すると、概略的に説明されているＩＭＳネットワーク１および信頼される企業ネットワーク２がある。企業ネットワーク２は、ＩＰ−ＰＢＸと表示されている構内交換機（ＰＢＸ）を含む。ＩＰ−ＰＢＸは、ユーザ端末のグループの代わりに、ＩＭＳネットワーク１と手続きを行う。ＩＰ−ＰＢＸは、ＤＨＣＰの参照により、ＩＭＳネットワーク内に位置するアウトバウンドのＰ−ＣＳＣＦ３のアドレスを得る（ＩＥＴＦ ＲＦＣ ３２６３に仕様化されているとおり）。ＩＰ−ＰＢＸは、自らのＰＵＩを使用してＩＭＳネットワークと手続きを行う（この例では、"pbx1@operator.com"）。ＩＭＳネットワーク１内のＨＳＳ４は、ＩＰ−ＰＢＸのための加入情報を保存する。当該加入情報には、ＩＰ−ＰＢＸを介してＩＭＳネットワークにアクセスできる全てのユーザを包含する暗黙的登録セットを含む。ＩＰ−ＰＢＸのＰＵＩおよびＩＰ−ＰＢＸに割り当てられるｔｅｌ ＵＲＩに加えて、暗黙的登録セットは、ＰＢＸに関連付けられるＰＵＩの範囲を表す「ワイルドカード化された」ＰＵＩを含む。この例では、ワイルドカード化されたＰＵＩは、"!x!@enterprise2.com"である。上記ワイルドカード化されたＰＵＩのコンポーネント"!x!"は、特定されたサフィックスおよび任意のプレフィクスを有するＰＵＩが、ワイルドカード化されたＰＵＩに一致することを示す。

ＨＳＳ ４は、関連付けられるサービスプロファイルと共に、サーバ指定応答（Server Assignment Answer）の中でＳ−ＣＳＣＦ７に暗黙的登録セットを送信する。その後、Ｓ−ＣＳＣＦ７は、Ｉ−ＣＳＣＦ（示されていない）およびＰ−ＣＳＣＦを介して２００ ＯＫメッセージをＩＰ−ＰＢＸに送信する。当該２００ ＯＫメッセージは、ＰＢＸのＰＵＩに関連付けられる暗黙的登録セット内のＰＵＩを識別するＰアサーテドＵＲＩフィールドを含む。

信頼される企業ネットワーク内の端末が、別の端末に呼を転送したい場合を考えると、ＩＤ Cassandra@enterprise3.comを有する第１の端末５は、ＩＤ Bob@enterprise2.com を有する第２の端末６に発呼する。第１の端末５から送信されるメッセージは、"From"フィールド内のＵＲＩであるCassandra@enterprise3.com、および"To"フィールド内のＵＲＩであるBob@enterprise2.comを、ヘッダに含む。メッセージは、Cassandra@enterprise3.comのＰ−アサーテドＩＤも含む。しかしながら、Bob@enterprise2.comへ送信されたメッセージは、Alice@enterprise1.comへ転送されることになっている。

メッセージは、Alice@enterprise1.comに転送するためにＩＰ−ＰＢＸに戻され、ＩＰ−ＰＢＸは、これがＩＭＳネットワーク１内のＰ−ＣＳＣＦ３に送信されなければならないと判定する。ＩＰ−ＰＢＸは、ＩＮＶＩＴＥメッセージをＰ−ＣＳＣＦ３に送信し、当該ＩＮＶＩＴＥメッセージは、AliceのＵＲＩ、"From"フィールド内にCassandraのＵＲＩ、および"To"フィールド内にBobのＵＲＩを含む。このＩＮＶＩＴＥは、CassandraのＰ−アサーテドＩＤも含む。

企業ネットワーク２内のＩＰ−ＰＢＸとＩＭＳネットワーク１との間には、信頼関係が存在することに留意する。Ｐ−ＣＳＣＦ３が、登録の間に形成されたセキュリティ接続上でＳＩＰ ＩＮＶＩＴＥを受信するため、Ｐ−ＣＳＣＦは、ＩＮＶＩＴＥがpbx1@operator1.comの代わりに処理されることになっていることを知っている。Ｐ−ＣＳＣＦ３は、ＩＭＳネットワーク１の信頼できるドメインが、企業ネットワーク２のＩＰ−ＰＢＸへ拡張することも知っている。Ｐ−ＣＳＣＦ３は、Ｐ−アサーテドＩＤを修正せずに送り、新たなヘッダをＩＮＶＩＴＥに挿入する。当該新たなヘッダは、「Ｐ−サーブドユーザ」と呼ばれる。Ｐ−サーブドユーザヘッダは、pbx1@operator1.comであるＩＰ−ＰＢＸのＵＲＩを含む。ある実施形態では、Ｐ−アサーテドＩＤが、メッセージが受信されたＩＤと一致しない場合にのみ、Ｐ−ＣＳＣＦ３は、Ｐ−サーブドユーザヘッダを挿入することに留意する。この例では、Ｐ−アサーテドＩＤが信頼されるエンティティの属する暗黙的登録セットの要素ではない場合にのみ、Ｐ−ＣＳＣＦは、Ｐ−サーブドユーザヘッダを挿入する。

Ｐ−ＣＳＣＦ３は、Ｐ−サーブドユーザヘッダを含むＳＩＰ ＩＮＶＩＴＥをＳ−ＣＳＣＦ７に転送する。pbx1@operator.comの加入に関連付けられるｉＦＣは、ＩＮＶＩＴＥが、アプリケーションサーバ（ＡＳ）８を転送する呼によって、処理されることになっていることを示し得る。この場合、Ｓ−ＣＳＣＦ７は、ルートヘッダの最上位のＵＲＩとして、ＡＳ８のＳＩＰ ＵＲＩを付け加え、「オリジナルダイヤログ識別子」（ＯＤＩ）共に、ルートヘッダ内におけるＡＳのＵＲＩの下に自らのＳＩＰ ＵＲＩを含める標準的な動作を実行する。メッセージは、その後、ＩＳＣインターフェースを介してＡＳ８に転送される。Ｓ−ＣＳＣＦ７は、ＩＮＶＩＴＥが関連するセッションの状態情報を維持する。この情報は、ＯＤＩおよびサービスを受けるユーザのＩＤを含む。

また、Ｓ−ＣＳＣＦ７は、Ｐ−アサーテドＩＤよりもむしろ、Ｐ−サーブドユーザに基づいてサービスを受けるユーザを判定する。これにより、ＳＩＰ ＩＮＶＩＴＥに含まれるＰ−アサーテドＩＤよりもむしろ、ＩＰ−ＰＢＸに関連付けられるＩＰ−ＰＢＸのＩＤに基づいた認証が可能となる。

もしＰ−サーブドユーザヘッダが、ＳＩＰ ＩＮＶＩＴＥ中に含まれていない場合、ＩＭＳネットワークのノードは、Ｐ−アサーテドＩＤ（この場合、Cassandra@enterprise3.com）上で認証の実行を試みる。Cassandra@enterprise3.comがＩＭＳネットワークまたは付随する企業ネットワークに属さなければ、Ｐ−アサーテドＩＤを使用する認証は失敗する。

本発明により、Ｐ−ＣＳＣＦは、ＳＩＰ ＩＮＶＩＴＥ中における、ネットワークにアサート（主張）された（network asserted）発信側ユーザ（Cassandra@enterprise3.com）のＩＤとは別個の情報の要素内のサービスを受けるユーザ（Bob@enterprise2.com）と通信することが可能となる。Ｓ−ＣＳＣＦ７は、これを使用してサービスを受けるユーザを判定する。これは、企業ネットワークが、信頼されるネットワークとして取り扱われることを可能にする。

図３は、本発明の実施形態の基本的なステップを説明するフロー図である。以下の符号は、図３の符号を参照する：

Ｓ１．Ｐ−ＣＳＣＦは、登録中に形成されたセキュリティ接続上で、ＩＰ−ＰＢＸからＳＩＰメッセージを受信する。

Ｓ２．ＩＰ−ＰＢＸがＩＭＳネットワークの加入を有し、ネットワークにアサートされた発信側ユーザはそのような加入を有していない可能性がある場合に、既存のセキュリティ接続上でＳＩＰメッセージを受信し、メッセージが信頼されるエンティティからきていると認識し、Ｐ−アサーテドＩＤが暗黙的に登録されたＩＤのセットに属さないことを判定することにより、Ｐ−ＣＳＣＦは、ＳＩＰメッセージに、Ｐ−サーブドユーザヘッダの形でＩＰ−ＰＢＸのＵＲＬを付け加え、任意に存在するＰ−アサーテドＩＤヘッダをそのまま残す。

Ｓ３．ステップ２から生成されるＳＩＰメッセージは、Ｓ−ＣＳＣＦに送信される。

Ｓ４．Ｐ−サーブドユーザヘッダの存在に気付いたＳ−ＣＳＣＦは、Ｐ−アサーテドＩＤを無視し、Ｐ−サーブドユーザヘッダを使用して、手続きの処理のためにサービスを受けるユーザを判定する。ｉＦＣが、サービスを受けるユーザのためにアクティブ化されている場合、ＳＩＰメッセージは、ＡＳに転送され得る。

Ｓ５．メッセージが、その後ＡＳにより受信される場合、Ｐ−サーブドユーザヘッダの存在に気付いたＡＳは、Ｐ−サーブドユーザヘッダを使用して、関連する手続きの処理のためにサービスを受けるユーザを判定する。

図４は、本発明の実施形態に従ったＰ−ＣＳＣＦ３を概略的に説明している。Ｐ−ＣＳＣＦ３は、ＩＰ−ＰＢＸからＳＩＰメッセージを受信するための受信部９を有する。メモリ１０は、ＩＰ−ＰＢＸに関連する加入情報を保存するために提供され、処理部１１は、ＩＰ−ＰＢＸに関連する加入を識別するＰ−サーブドユーザヘッダを、ＳＩＰメッセージに付け加えるために提供される。送信部１２は、また、Ｓ−ＣＳＣＦのようなさらなるノードにＳＩＰメッセージを送信するために提供される。

図５は、本発明の実施形態に従ったＳ−ＣＳＣＦ５を概略的に説明している。Ｓ−ＣＳＣＦ７は、Ｐ−ＣＳＣＦ３からＳＩＰメッセージを受信するための受信部１３、およびＳＩＰメッセージがＰサーブドヘッダを含むかを判定するための処理部１４を有する。Ｐ−サーブドユーザヘッダがＳＩＰメッセージ内に存在する場合、次に、Ｐ−アサーテドＩＤの代わりにＰ−サーブドユーザヘッダが使用されて、サービスを受けるユーザが判定される。送信部１５は、また、さらなる処理のために、ＩＭＳネットワーク内の他のノードに上記メッセージを送信するために提供されている。

図６は、本発明の実施形態に従ったＡＳ８を概略的に説明している。ＡＳ８は、ＳＩＰメッセージを受信するための受信部１６、およびＳＩＰメッセージがＰ−サーブドユーザヘッダを含むかを判定するための処理部１７を有する。Ｐ−サーブドユーザヘッダがＳＩＰメッセージ内に存在する場合、次に、Ｐ−アサーテドＩＤヘッダの代わりにＰ−サーブドユーザヘッダが使用されて、サービスを受けるユーザが判定される。ＡＳは、また、ＩＭＳネットワーク内の他のノードにメッセージを送信するための送信部１８を有する。

本発明の範囲から外れることなく、上記の実施形態に対して様々な改良が実施され得ることは、当業者により理解されるだろう。例えば、上記は、企業ネットワーク内のＩＰ−ＰＢＸのノードに言及する。しかしながら、本発明は、接続されたＳＩＰプロキシノード、または企業ネットワーク若しくは他の種類のネットワークに配置されるＳＩＰ Ｂ２ＢＵＡにも適用される。

Claims (11)

1. ＩＰマルチメディアサブシステムネットワーク内でセッション開始プロトコルの通信をハンドリングする方法であって：
   プロキシ呼セッション制御機能で、遠隔ネットワーク内に位置する信頼されるエンティティによりＩＤがアサートされた別のエンティティから発信され、前記信頼されるエンティティから送信されるセッション開始プロトコルのメッセージを受信するステップと；
   前記プロキシ呼セッション制御機能で、前記信頼されるエンティティのＩＤが前記メッセージのＰ−アサーテドＩＤ（P-Asserted-ldentity）に含まれるＩＤと一致しないことを判定するステップと；
   前記判定がされた場合には、前記プロキシ呼セッション制御機能で、サービング呼セッション制御機能によりサービスを提供される前記遠隔ネットワークにおける信頼されるエンティティのパブリックユーザＩＤを識別する追加ヘッダを前記メッセージに付け加えるステップと；
   前記サービング呼セッション制御機能に前記メッセージを送信するステップと；
   を含む方法。
2. 前記メッセージが受信されたセキュアなチャネルのＩＤを判定することにより、前記信頼されるエンティティの前記パブリックユーザＩＤを取得するステップ
   をさらに含む、請求項１に記載の方法。
3. 前記サービング呼セッション制御機能で、前記追加ヘッダの存在を識別し、前記Ｐ−アサーテドＩＤの代わりに、前記信頼されるエンティティの前記パブリックユーザＩＤを使用して、サービス提供されるユーザを判定すること
   をさらに含む、請求項１または２に記載の方法。
4. 遠隔ネットワークから送信されるセッション開始プロトコルの前記メッセージは、ビジネストランクを介して送信される、
   請求項１、２または３のいずれか１項に記載の方法。
5. 前記パブリックユーザＩＤを識別する前記追加ヘッダは、前記ＩＰマルチメディアサブシステムネットワーク内に位置するホーム加入者サーバおよびユーザプロファイルサーバ機能のうちの１つに保存される前記信頼されるエンティティのパブリックユーザＩＤに関連する加入情報から取得される、
   請求項１から４のいずれか１項に記載の方法。
6. 前記信頼されるエンティティのパブリックユーザＩＤに関連する前記加入情報は、ワイルドカード化されたパブリックユーザＩＤ、またはパブリックユーザＩＤの範囲に関するパブリックユーザＩＤのサブドメイン表現を含む、暗黙的登録セットを含む、
   請求項５に記載の方法。
7. セッション開始プロトコルの前記メッセージは、セッション開始プロトコルのＩＮＶＩＴＥメッセージである、
   請求項１に記載の方法。
8. ＩＰマルチメディアサブシステムネットワーク内での使用のためのプロキシ呼セッション制御機能ノードであって：
   遠隔ネットワーク内に位置する信頼されるエンティティによりＩＤがアサートされた別のエンティティから発信され、前記信頼されるエンティティから送信されるセッション開始プロトコルのメッセージを受信するための受信部と；
   前記ＩＰマルチメディアサブシステムネットワーク内に位置するホーム加入者サーバおよびユーザプロファイルサーバ機能のうちの１つから、前記信頼されるエンティティのパブリックユーザＩＤに関連する加入情報を受信し、前記信頼されるエンティティのＩＤが前記メッセージのＰ−アサーテドＩＤに含まれるＩＤと一致しないことを判定するための手段と；
   前記判定がされた場合には、サービング呼セッション制御機能によりサービス提供される前記遠隔ネットワーク内の信頼されるエンティティのパブリックユーザＩＤを識別する追加ヘッダを、前記メッセージに付け加えるための処理部と、
   前記サービング呼セッション制御機能に前記メッセージを送信するための送信部と；
   を有するプロキシ呼セッション制御機能ノード。
9. 前記信頼されるエンティティのパブリックユーザＩＤに関連する前記加入情報は、暗黙的登録セットを含み、
   前記暗黙的登録セットは、ワイルドカード化されたパブリックユーザＩＤ、またはパブリックユーザＩＤの範囲に関するパブリックユーザＩＤのサブドメイン表現を含む、
   請求項８に記載のプロキシ呼セッション制御機能ノード。
10. ＩＰマルチメディアサブシステムネットワーク内での使用のためのサービング呼セッション制御機能ノードであって：
    遠隔ネットワーク内のユーザから発信され、前記遠隔ネットワーク内の信頼されるエンティティを介してプロキシ呼セッション制御機能ノードに送信されたセッション開始プロトコルのメッセージを、前記プロキシ呼セッション制御機能ノードから受信するための受信部と；
    前記サービング呼セッション制御機能ノードによりサービス提供される前記遠隔ネットワーク内の前記信頼されるエンティティのパブリックユーザＩＤを識別する追加ヘッダがセッション開始プロトコルの前記メッセージ内に存在するかを識別するための処理部と；
    前記追加ヘッダが識別された場合に、Ｐ−アサーテドＩＤの代わりに、前記信頼されるエンティティの前記パブリックユーザＩＤをサービスを受ける前記ユーザのＩＤとして使用するための手段と；
    を有するサービング呼セッション制御機能ノード。
11. ＩＰマルチメディアサブシステムネットワーク内での使用のためのアプリケーションサーバであって：
    遠隔ネットワーク内のユーザから発信され、前記遠隔ネットワーク内の信頼されるエンティティを介してプロキシ呼セッション制御機能ノードに送信されたセッション開始プロトコルのメッセージを受信するための受信部と；
    ＩＰマルチメディアサブシステムネットワーク内のサービング呼セッション制御機能によりサービス提供される前記遠隔ネットワーク内の前記信頼されるエンティティのパブリックユーザＩＤを識別する追加ヘッダがセッション開始プロトコルの前記メッセージ内に存在するかを識別するための処理部と；
    前記追加ヘッダが識別された場合に、Ｐ−アサーテドＩＤの代わりに、前記信頼されるエンティティの前記パブリックユーザＩＤをサービスを受ける前記ユーザのＩＤとして使用するための手段と；
    を有するアプリケーションサーバ。
    

Images