JP2010532591A

JP2010532591A - Ｉｐマルチメディアサブシステムサービスへのグループアクセス

Info

Publication number: JP2010532591A
Application number: JP2009550689A
Authority: JP
Inventors: エルブルグ，ハンス−エリックヴァン; フレドリックリンドホルム，; パトリックティメルズ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-02-22
Filing date: 2008-02-12
Publication date: 2010-10-07
Anticipated expiration: 2028-02-12
Also published as: US20120011273A1; US8260957B2; RU2009135247A; JP5249952B2; US20120296953A1; US8700692B2; WO2008101838A2; WO2008101838A3; RU2474067C2

Abstract

ＩＰマルチメディアサブシステムユーザの標準処理に対して代替処理を必要とするユーザグループからの、ＩＰマルチメディアサブシステムのサービスへのアクセスを促進する方法。ＩＰマルチメディアサブシステム内に維持されるユーザグループのサブスクリプションに機能指示が追加され、ＩＰマルチメディアサブシステム内のノードに、この特定のグループのユーザに対してそれらの標準機能を適合させるように指示する。特定のユーザグループのサブスクリプションの中の指示は、ＩＰマルチメディアサブシステムのノードが特定のタイプのユーザに対して固有である必要はもはやなく、動作の標準的なやり方を有するが、その動作がその特定のユーザグループだけに専用の動作を指示することにより変更されることを規定している。さらなる態様では、ＩＰマルチメディアサブシステムの周知の問題に対して、サブスクリプションに含まれた機能指示を利用する改善した解決手段を提供する実施形態が開示される。

Description

本発明は、ＩＰマルチメディアサブシステムサービスへのグループアクセスに関し、特に、ＩＰマルチメディアサブシステムに個別に加入していないが加入しているグループに属するユーザの、そのようなアクセスを促進することに関する。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動通信網を通じてＩＰマルチメディアサービスを提供するために、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって規定された技術である（非特許文献１）。ＩＭＳは、サービスの統合および相互作用を通して、エンドユーザの個人対個人の通信エクスペリエンスを豊かにするために重要な機能を提供する。ＩＭＳは、ＩＰベースのネットワーク上で新しいリッチな個人対個人（クライアント対クライアント）通信および個人対コンテンツ（クライアント対サーバ）通信を可能にする。

ＩＭＳは、ユーザ端末（ＵＥ）間またはＵＥとアプリケーションサーバ（ＡＳ）との間の呼またはセッションを設定および制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングで伝達されるセッション記述プロトコル（ＳＤＰ）が、セッションのメディアコンポーネントを記述し、ネゴシエートするために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳは、オペレータおよびサービスプロバイダがサービスへのユーザアクセスを制御し、アクセスに応じてユーザに課金することを可能にする。ＳＩＰもＳＤＰも、標準ＵＤＰおよびＴＣＰインターネットプロトコルによって伝達される。１３００バイト以下のＳＩＰまたはＳＤＰメッセージは、ＵＤＰによって伝達されるであろうが、それを超えるとそれらの伝送にＴＣＰが使用される。

ＩＭＳネットワーク内では、呼／セッション制御機能（ＣＳＣＦ）がＩＭＳ内のＳＩＰエンティティとして動作する。３ＧＰＰのアーキテクチャは、３種類のＣＳＣＦを規定しており、ＳＩＰ端末に対するＩＭＳ内の最初の接触点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、および正しいＳ−ＣＳＣＦを識別し、そのＳ−ＣＳＣＦにＳＩＰ端末からＰ−ＣＳＣＦを介して受信した要求を転送する役割を有するインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。

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

ユーザは、指定のＳＩＰ登録方法を用いてＩＭＳに登録する。これは、ＩＭＳに接続して、ＳＩＰユーザアイデンティティに到達できるアドレスをＩＭＳにアナウンスするメカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を実行するとき、ＩＭＳは、ホーム加入者サーバ（ＨＳＳ）に格納されたサブスクリプション（加入）情報を用いてユーザを認証し、利用可能なＳ−ＣＳＣＦのセットの中から１つのＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰによって指定されていないが、基準の中には負荷分担およびサービス要件が含まれてもよい。Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスへのユーザアクセスを制御し課金するために重要であるこが知られている。オペレータは、直接のユーザ対ユーザのＳＩＰセッションを防ぐメカニズムを提供してもよく、そうしないとセッションがＳ−ＣＳＣＦを迂回するであろう。

登録プロセス中でＳ−ＣＳＣＦがまだ選択されていない場合に、Ｓ−ＣＳＣＦの選択はＩ−ＣＳＣＦが担当する。Ｉ−ＣＳＣＦは、ＨＳＳから所要のＳ−ＣＳＣＦ機能を受信し、受信した機能に基づき適切なＳ−ＣＳＣＦを選択する。ユーザが別のユーザからの電話を受け、かつそのユーザが現在Ｓ−ＣＳＣＦを割り当てられていない場合も、ユーザに対するＳ−ＣＳＣＦの割り当てはＩ−ＣＳＣＦによって行われることが知られている。登録されたユーザが続いてＩＭＳにセッション要求を送信すると、Ｐ−ＣＳＣＦは、登録プロセス中に選択したＳ−ＣＳＣＦから受信した情報に基づき、そのＳ−ＣＳＣＦに要求を転送できる。

あらゆるＩＭＳユーザは、１つ以上のプライベート・ユーザ・アイデンティティを所有する。プライベート・ユーザ・アイデンティティは、ホームネットワークオペレータによって割り当てられ、例えば登録、認可、管理および課金目的で、ＩＭＳによって使用される。このアイデンティティは、非特許文献２に定義されるネットワークアクセス識別子（ＮＡＩ）の形態をとる。プライベートアイデンティティに関して、ＮＡＩ内に国際移動電話加入者識別番号（ＩＭＳＩ）表示を含めることが可能である。非特許文献３は、プライベート・ユーザ・アイデンティティの以下の特性を明確に述べている。
−プライベート・ユーザ・アイデンティティは、ＳＩＰメッセージのルーティングに使用されない。
−プライベート・ユーザ・アイデンティティは、ＵＥからホームネットワークに伝達されるすべての登録要求（再登録要求および登録取消要求を含む）に含まれるものとする。
−ＩＰマルチメディア・サービス・アイデンティティ・モジュール（ＩＳＩＭ）アプリケーションは、１つのプライベート・ユーザ・アイデンティティを安全に格納するものとする。ＵＥがＩＳＩＭアプリケーションに格納されたプライベート・ユーザ・アイデンティティ情報を変更することが可能であってはならない。
−プライベート・ユーザ・アイデンティティは、ホームネットワークオペレータによって定められる一意のグローバルアイデンティティであり、ネットワークの観点からユーザのサブスクリプション（例えば、ＩＭサービス性能）を確認するためにホームネットワーク内で使用されてもよい。プライベート・ユーザ・アイデンティティは、ユーザではなくサブスクリプションを識別する。
−プライベート・ユーザ・アイデンティティは、ユーザのサブスクリプションに永続的に割り当てられるものとし（動的なアイデンティティではない）、ホームネットワークとユーザとの加入期間中有効である。
−プライベート・ユーザ・アイデンティティは、（例えば登録中に使用するために）ＨＳＳ内に格納されたユーザ情報（例えば認証情報）を識別するために使用される。
−プライベート・ユーザ・アイデンティティは、オペレータポリシーに基づき課金記録の中にあってもよい。
−プライベート・ユーザ・アイデンティティは、ユーザの登録中（再登録および登録取消を含む）だけ認証される。
−ＨＳＳは、プライベート・ユーザ・アイデンティティを格納する必要がある。
−Ｓ−ＣＳＣＦは、登録時および未登録の着信時、プライベート・ユーザ・アイデンティティを取得し格納する必要がある。

プライベート・ユーザ・アイデンティティに加えて、あらゆるＩＭＳユーザは、１つ以上のＩＭＳパブリック・ユーザ・アイデンティティ（ＰＵＩ）を有するものとする。ＰＵＩは、他のユーザへの通信を要求するために、あらゆるユーザが使用する。ユーザは、例えば名刺に（プライベート・ユーザ・アイデンティティではなく）ＰＵＩを記載してもよい。非特許文献３は、ＰＵＩの以下の特性を明確に述べている。
−ユーザが有するＰＵＩに応じて、電話番号付与スキームとインターネット命名スキームの両方とも、ユーザにアドレスを指定するために使用されてもよい。
−ＰＵＩは（非特許文献４および非特許文献５に定義されているような）ＳＩＰＵＲＩの形態（あるいは非特許文献６に定義されている「ｔｅｌ：」−ＵＲＩフォーマット）を取るものとする。
−ＩＳＩＭアプリケーションは、少なくとも１つのＰＵＩを安全に格納するものとする（ＵＥがＰＵＩを変更することが可能であってはならない）が、追加のすべてのＰＵＩがＩＳＩＭアプリケーションに格納される必要はない。
−ＰＵＩが明示的または暗黙的に登録されてから、ＩＭＳセッション手順およびＩＭＳセッションに関係ない手順を始めるために、アイデンティティが使用できるものとする。
−ＰＵＩが明示的または暗黙的に登録されてから、ＩＭＳセッションの終了およびＩＭＳセッションに関係ない手順の終了を、ＰＵＩが属するユーザのＵＥに配信できるものとする。
−１つ以上のＰＵＩを有するユーザをＩＭＳ内のメカニズムによって（例えば、暗黙的な登録セットを用いて）包括的に登録する（すなわち、１つのＵＥ要求だけで登録する）ことができるものとする。これは、必要な場合にユーザのＰＵＩの幾つかをユーザが個別に登録するのを妨げないものとする。
−ＰＵＩは、登録中にネットワークによって認証されない。
−ＰＵＩは、（例えば、移動端末への着信セッション設定中に）ＨＳＳ内のユーザ情報を確認するために使用されてもよい。
−ＰＵＩは、ユーザに適用されるサービス設定データを確認するために、ＩＭＳ内のＡＳによって使用されてもよい。

ＩＭＳユーザは、１つ以上のＩＭＳサブスクリプションを有する。ＩＭＳサブスクリプションは、１つのプライベート・ユーザ・アイデンティティおよび少なくとも１つのサービスプロファイルを有する。サービスプロファイルには、少なくとも１つのパブリック・ユーザ・アイデンティティを含む。パブリック・ユーザ・アイデンティティは、１つのサービスプロファイルだけに関連づけることが可能であるのに対して、プライベート・ユーザ・アイデンティティは１つ以上のサービスプロファイルに関連づけてもよい。図１は、ＩＭＳのユーザ、ユーザのＩＭＳサブスクリプション、パブリック・ユーザ・アイデンティティおよびプライベート・ユーザ・アイデンティティの間の関係例を図式的に示す。図の例では、加入者は、１つのＩＭＳサブスクリプションにそれぞれが関連づけられている２つのプライベート・ユーザ・アイデンティティを有し、両方とも２つのパブリック・ユーザ・アイデンティティに関連づけられている（パブリック・ユーザ・アイデンティティの１つであるパブリック・ユーザ・アイデンティティ２が、両方のプライベート・ユーザ・アイデンティティに関連づけられている）。サービスプロファイルは、各パブリック・ユーザ・アイデンティティに関連づけられている、このプロファイルは、関連づけられているパブリック・ユーザ・アイデンティティのサービスデータを指定する。サービスプロファイルは、ホーム加入者サーバ（ＨＳＳ）でユーザに対してアプリケーションサーバが用意されるとき、作成または変更される。各サービスプロファイルは、ＩＭＳサービスの提供または制限をトリガするために使用される初期フィルタ基準（ｉＦＣ）を１つ以上備える。サービスプロファイル１およびサービスプロファイル２によって提供されるサービス間の差異はオペレータ固有であるが、異なるアプリケーションサーバ（ＡＳ）、さらに異なる課金／料金スキームさえかかわってもよい。

例では、パブリック・ユーザ・アイデンティティ１がサービスプロファイル１に関連づけられているのに対して、パブリック・ユーザ・アイデンティティ２およびパブリック・ユーザ・アイデンティティ３はサービスプロファイル２に関連づけられている。典型的なシナリオでは、パブリック・ユーザ・アイデンティティ１は、ユーザが友人および家族に教えるアイデンティティ例えば「Ｂｉｇ＿Ｊｏｅ＠ｐｒｉｖ．ｏｐｅｒａｔｏｒ．ｃｏｍ」でもよいのに対して、パブリック・ユーザ・アイデンティティ２およびパブリック・ユーザ・アイデンティティ３は、ユーザが取引相手に教えるアイデンティティ例えば「＋４６１１１２２２３３３＠ｏｐｅｒａｔｏｒ．ｃｏｍ」および「ｊｏｅ．ｂｌａｃｋ＠ｏｐｅｒａｔｏｒ．ｃｏｍ」でもよい。

３ＧＰＰは、グループとして働くＰＵＩのセットで、そのセットの中のＰＵＩの任意の１つが登録または登録取消しされると一緒に登録および登録取消しされるＰＵＩのセットを取り扱うために、いわゆる「暗黙的な登録セット（ＩｍｐｌｉｃｉｔＲｅｇｉｓｔｒａｔｉｏｎＳｅｔ）」の概念を定めている。ＩＭＳユーザ端末の登録時またはまだ登録されていないときにユーザ端末に対する接続要求受信時、Ｉ−ＣＳＣＦによるトリガ後、Ｓ−ＣＳＣＦは、Ｉ−ＣＳＣＦからのトリガの中で受信したプライベート・ユーザ・アイデンティティおよびパブリック・ユーザ・アイデンティティによって識別されるサブスクリプションの詳細（ユーザプロファイルとも示される）をＨＳＳに要求する。上述のように、サブスクリプション（ユーザプロファイル）は、１つ以上のサービスプロファイルを含み、各サービスプロファイルは、１つ以上のパブリック・ユーザ・アイデンティティを含む。例えば図１のユーザプロファイル１を参照されたい。ユーザプロファイル内のパブリック・ユーザ・アイデンティティのすべてが一緒になって、暗黙的な登録セットと呼ばれる。

理解目的で、標準登録手順のより詳細な説明について、これから図２を参照して行う。ＵＥがセッションを設定できるようになる前またはＩＭＳサービスを組み込みできるようになる前には、ＵＥはＩＭＳに登録する必要がある。以下の例では、ＪｏｅＢｌａｃｋが彼のパブリックアイデンティティ「Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」で、ＩＭＳ加入をしているオペレータ１のＩＭＳに登録する。図１はメッセージの大要を示す。実際の登録プロセスは２つのフェーズから成る。第１のフェーズでは、保護されていないＲＥＧＩＳＴＥＲメッセージがＳ−ＣＳＣＦに送信される。Ｓ−ＣＳＣＦは第１のステップでＵＥ／ＰＵＩを認証し、ＳＩＰ４０１メッセージでＵＥにチャレンジ（ｃｈａｌｌｅｎｇｅ）を返信する。ＵＥはチャレンジを使用してレスポンスを計算し、それは、登録フェーズ２の次のＲＥＧＩＳＴＥＲメッセージの中で送信される。レスポンスの計算のほかに、２つのフェーズ間のこの時間は、ＵＥがＰ−ＣＳＣＦとセキュアＩＰチャネル（ＩＰ−Ｓｅｃ）をネゴシエートするためにも使用される。Ｓ−ＣＳＣＦは、第２の登録を受け付けると、認可を完了し、ＵＥ／ＰＵＩを登録する。登録が完了すると、ＳＩＰ２００メッセージがＵＥに返信される。登録の完了後、Ｓ−ＣＳＣＦは、ＨＳＳから取得したユーザプロファイルの中のｉＦＣによって示されたすべての関連するＩＭＳアプリケーションに、ＰＵＩをさらに登録する。

ＵＥがＲＥＧＩＳＴＥＲメッセージを組み立てできるようになる前には、ＵＥは、Ｐ−ＣＳＣＦのＩＰアドレスを獲得する必要がある。このアドレスはＵＥに格納されていてもよいが、もっとありそうなのはＰ−ＣＳＣＦのエリアスが格納されていることであり、ＵＥはＤＨＣＰおよび／またはＤＮＳによって正しいＩＰアドレスを得る必要がある。次いでＵＥは、ＲＥＧＩＳＴＥＲメッセージを組み立て、それをＰ−ＣＳＣＦに向けて送信する。メッセージ（図２の１）を簡潔な形態で以下に示す。本発明の説明に関連するフィールドだけを検討する。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＲＥＧＩＳＴＥＲｓｉｐ：ｏｐｅｒａｔｏｒｌ．ｃｏｍ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰｏｆＪｏｅＢｌａｃｋｓＵＥ＞；ｂｒａｎｃｈ＝０ｕｅｔｂ
Ｒｏｕｔｅ：＜ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＰ−ＣＳＣＦ＞
Ｍａｘ−Ｆｏｒｗａｒｄｓ：５０
Ｆｒｏｍ：Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｔｏ：Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｃｏｎｔａｃｔ：＜ｃｕｒｒｅｎｔＩＰｏｆＪｏｅＢｌａｃｋｓＵＥ＞；ｅｘｐｉｒｅｓ＝２０００
Ｃａｌｌ−ＩＤ：ｇｒｔ３８ｕ６ｙｑｒ５４ｇｆｋｐ９８ｙ６ｔ３ｒｒ
ＣＳｅｑ：２５ＲＥＧＩＳＴＥＲ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

メッセージのタイプはＲＥＧＩＳＴＥＲである。ＣＳｅｑおよびＣａｌｌ−ＩＤは、この登録処理の一意の識別番号を与える。メッセージは、基本的に（音声またはビデオパッケージのような）ペイロードのないメッセージヘッダだけであり、従ってコンテンツ長（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ）はゼロに設定される。最初の宛先は、「ＳＩＰ：ｏｐｅｒａｔｏｒ１．ｃｏｍ」によって与えられるが、それが、ＵＥが登録したいところだからである。Ｆｒｏｍフィールドは、ＪｏｅＢｌａｃｋが使用を望む彼のパブリック・ユーザ・アイデンティティを与える。Ｔｏフィールドは、それに対して主要な登録が要求されているので同一である。Ｃｏｎｔａｃｔフィールドは、ＵＥの現在のＩＰアドレスを含み、ｅｘｐｉｒｅｓは、ＩＰアドレスが有限の期間リースされるとき、残りのリース期間を示す。それは、ＴｏフィールドのＳＩＰＵＲＩがＣｏｎｔａｃｔフィールドのＩＰアドレスにどのくらいの期間結び付けられているかを示す。

Ｒｏｕｔｅフィールドは、メッセージが送信される次のＳＩＰエンティティを毎回含む。メッセージが通過した各ＳＩＰエンティティは、戻りのパスを作成するために、Ｖｉａヘッダに自エンティティを付け加える。最大転送回数（Ｍａｘ−Ｆｏｒｗａｒｄｓ）は、ＩＰネットワーク内でメッセージがバウンス（ｂｏｕｎｃｉｎｇ）し始めるのを防ぐために、各ＳＩＰエンティティを通過後１だけ減らされる。この値がゼロになると、メッセージは削除される。

メッセージがＰ−ＣＳＣＦに到着すると、Ｐ−ＣＳＣＦは、Ｒｏｕｔｅヘッダから自装置のアドレスを取り去り、それをＶｉａヘッダに付ける。次いでＰ−ＣＳＣＦは、メッセージをどのＩ−ＣＳＣＦに転送するかのチェックを開始する。このＩ−ＣＳＣＦは、別のオペレータの別のネットワークにあってもよい。それ故、Ｐ−ＣＳＣＦは、ＲＥＧＩＳＴＥＲフィールドの被要求ＵＲＩとＤＮＳを使用してドメイン名を解決し、その結果生じたＤＮＳクエリ、ＮＡＰＴＲクエリ、ＳＲＶクエリおよびＡＡＡＡクエリを使用してＩ−ＣＳＣＦアドレスを取得する。しかしＰ−ＣＳＣＦは、Ｉ−ＣＳＣＦがＳＩＰエンティティ機能を実行するか、または適切な別のＩ−ＣＳＣＦへの単なるルータとして働くか確信が持てない。それ故、Ｐ−ＣＳＣＦは、Ｒｏｕｔｅフィールドにそのアドレスを付けず、ＳＩＰ登録メッセージを伝送する基礎を成すＵＤＰメッセージの宛先フィールドに付ける。さらにＰ−ＣＳＣＦは、自装置のアイデンティティを有するＰａｔｈフィールドを含める。Ｓ−ＣＳＣＦは、ＵＥ自体が隠されているので、ＵＥへの以降の応答を送信するための的確な場所としてＰａｔｈフィールドを使用してもよく、Ｐ−ＣＳＣＦは、ＵＥへのセキュアＩＰトンネルの入り口である。送信されるメッセージ２は、今は以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＲＥＧＩＳＴＥＲｓｉｐ：ｏｐｅｒａｔｏｒｌ．ｃｏｍ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＰ−ＣＳＣＦ＞；ｂｒａｎｃｈ＝０ｐｃｔｂ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰｏｆＪｏｅＢｌａｃｋｓＵＥ＞；ｂｒａｎｃｈ＝０ｕｅｔｂ
Ｒｏｕｔｅ：
Ｐａｔｈ：ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＰ−ＣＳＣＦ＞
Ｍａｘ−Ｆｏｒｗａｒｄｓ：４９
Ｆｒｏｍ：Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｔｏ：Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｃｏｎｔａｃｔ：＜ｃｕｒｒｅｎｔＩＰｏｆＪｏｅＢｌａｃｋｓＵＥ＞；ｅｘｐｉｒｅｓ＝２０００
Ｃａｌｌ−ＩＤ：ｇｒｔ３８ｕ６ｙｑｒ５４ｇｆｋｐ９８ｙ６ｔ３ｒｒ
ＣＳｅｑ：２５ＲＥＧＩＳＴＥＲ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

受信すると、Ｉ−ＣＳＣＦはそのアドレスをＶｉａヘッダに付ける。次いでＩ−ＣＳＣＦは、Ｓ−ＣＳＣＦのアドレスを取得する必要がある。それ故、ＨＳＳに位置情報要求３を行う。ＨＳＳは、位置情報回答４で応答する。Ｉ−ＣＳＣＦは、取得したＳ−ＣＳＣＦアドレスを使用するか、Ｓ−ＣＳＣＦアドレスを確認して、Ｒｏｕｔｅフィールドに付ける。メッセージ５は、以下のように今度は見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＲＥＧＩＳＴＥＲｓｉｐ：ｏｐｅｒａｔｏｒｌ．ｃｏｍ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＳ−ＣＳＣＦ＞；ｂｒａｎｃｈ＝０ｉｃｔｂ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＰ−ＣＳＣＦ＞；ｂｒａｎｃｈ＝０ｐｃｔｂ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰｏｆＪｏｅＢｌａｃｋｓＵＥ＞；ｂｒａｎｃｈ＝０ｕｅｔｂ
Ｒｏｕｔｅ：＜ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＳ−ＣＳＣＦ＞
Ｍａｘ−Ｆｏｒｗａｒｄｓ：４８
Ｆｒｏｍ：Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｔｏ：Ｂｉｇ＿Ｊｏｅ＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｃｏｎｔａｃｔ：＜ｃｕｒｒｅｎｔＩＰｏｆＪｏｅＢｌａｃｋｓＵＥ＞；ｅｘｐｉｒｅｓ＝２０００
Ｃａｌｌ−ＩＤ：ｇｒｔ３８ｕ６ｙｑｒ５４ｇｆｋｐ９８ｙ６ｔ３ｒｒ
ＣＳｅｑ：２５ＲＥＧＩＳＴＥＲ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｓ−ＣＳＣＦは、今やメッセージを受信したので、まず要求された登録が可能か、ＰＵＩが知られているかどうかの検証を始める。それ故、ＨＳＳに位置情報要求６を行う。ＨＳＳは、位置情報回答７で応答する。ＰＵＩは知られているが、全部の認証がまだ実行されていないので登録は拒否される。それ故、Ｓ−ＣＳＣＦは、４０１未認可メッセージをＵＥに返信する。このメッセージは、チャレンジキーを有するＷＷＷ認証フィールドを含む。認証および安全面の全部の詳細は、非特許文献７および非特許文献８に見つけることができる。

メッセージは、メッセージ８、９、１０によって同じ経路に従ってＵＥに戻る。戻りのルートは、Ｓ−ＣＳＣＦへの伝送中に組み立てられたＶｉａフィールドに示されている。各ＳＩＰエンティティは、（自エンティティである）最初のＶｉａヘッダを取り去り、次のＶｉａヘッダに経路を定める。さらに、Ｉ−ＣＳＣＦは、Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅフィールドを含める。ＵＥは、ＲＥＧＩＳＴＥＲメッセージ以外の他のすべてのメッセージに対してこれを使用できるので、Ｐ−ＣＳＣＦは、毎回正しいＩ−ＣＳＣＦを割り当てる長ったらしいタスクの実行から解放される。

ＵＥは、４０１未認可メッセージを受信するが、ここでＰ−ＣＳＣＦとセキュアＩＰトンネルのネゴシエーションを続ける。次いでＵＥは、Ｐ−ＣＳＣＦに対する応答およびＳ−ＣＳＣＦに対する応答を決める。第１の応答はＰ−ＣＳＣＦへの安全な接続を確立し、第２の応答はＳ−ＣＳＣＦが認証を完了して、登録を実行するためである。ＵＥの応答は、第２のＲＥＧＩＳＴＥＲメッセージの認可フィールドに含まれる。次のメッセージ１１、１２、１３、１４、１５のフローは、前のＲＥＧＩＳＴＥＲメッセージフロー１、２、３、４、５と全く同じである。

ここでＳ−ＣＳＣＦは、チャレンジレスポンスが正しいかどうかを調べ、次いでＨＳＳへの位置情報要求１６を続ける。ＨＳＳは、位置情報回答１７で応答する。回答は、Ｓ−ＣＳＣＦからの要求の中で与えられたプライベート・ユーザ・アイデンティティおよびパブリック・ユーザ・アイデンティティに基づいてＨＳＳが特定した、ユーザプロファイルを含む。ユーザプロファイルは、ＰＵＩに関連づけられているサービスプロファイルを含み、プライベート・ユーザ・アイデンティティに関連づけられているすべてのパブリック・ユーザ・アイデンティティの暗黙的な登録セットをＳ−ＣＳＣＦに提供する。そのようにして、これらのＰＵＩは、ＲＥＧＩＳＴＥＲメッセージのＰＵＩとともに暗黙的に登録される。ＵＥのＩＰアドレスは、ＲＥＧＩＳＴＥＲメッセージのｅｘｐｉｒｅフィールドに表される期間より長くない期間ＰＵＩに結び付けられる。この期間は、最長登録期間に関するオペレータポリシーにあまり依存しなくてもよい。

ここでの第１のステップは、Ｓ−ＣＳＣＦが、４０１未認可メッセージと同じやり方でＵＥに２００ＯＫメッセージを送信する。このメッセージフローは、メッセージ１８、１９、２０によって示されている。

第２のステップとして、Ｓ−ＣＳＣＦは、ユーザプロファイルに含まれるサービスプロファイルの中のｉＦＣフィールドを使用して、ｉＦＣフィールドに示されているＩＭＳアプリケーションにＲＥＧＩＳＴＥＲメッセージのＰＵＩを登録する。アプリケーションは、アプリケーションへのＲＥＧＩＳＴＥＲメッセージ２１の中で１つのＰＵＩだけを通知されることに注意されたい。暗黙的に登録された他のＰＵＩについての情報を取得するためには、それらは、Ｓ−ＣＳＣＦの登録状態（変更）情報を購読する必要がある。同様に、ＵＥは、他の暗黙的に登録されたＰＵＩの登録状態についての情報を得るために、２００ＯＫメッセージの受け取り直後、購読する必要がある。

上記の登録についての説明は、本発明の利点を理解するために必要な基本に過ぎない。より詳細な説明に関しては、非特許文献９の最新技術マニュアルに記載されている。

前述のＪｏｅＢｌａｃｋの場合は、１人のユーザが、複数のＰＵＩを有する１つのサブスクリプション（加入）を有していた。別の可能なＩＭＳの使用事例は、ＩＭＳへのグループレベルの加入をしているが、個別のユーザ自体ではサブスクリプションを持たないユーザの集まりを含む。一般に、このグループは、グループを代表してＩＭＳ向けのＳＩＰセッションの処理を扱うアクセスポイントを用いて隠されている。グループに代わって、アクセスポイントがＩＭＳに登録するので、それはＵＥに似ている。それにもかかわらず、それらのユーザに直接の外線着信および外線発信のダイアリングを可能にすることは、望ましいかまたは必要でさえある。これは、例えば、ＩＭＳのサブスクリプションを有し、ＩＰ構内交換機（ＩＰ−ＰＢＸ）に接続している個別の従業員機器または端末を有する企業の場合に生じるかもしれない。従業員端末は、ＳＩＰクライアントを備えていてもよいし、備えていなくてもよい。備えていない場合、ＩＰ−ＰＢＸは、ＳＩＰシグナリングと非ＳＩＰシグナリングとの間の変換を実行する。ＩＭＳが各端末に対する（同じ暗黙的な登録セット内の）個別のＰＵＩを記録することはもちろん可能かもしれないが、グループの規模が大きくなるにつれて、これは非効率になる。ＥＴＳＩＴＩＳＰＡＮは、このような企業ネットワークを次世代企業ネットワーク（ＮＧＣＮ、Next Generation Corporate Network）と定義している。

代替解決手段が図３および４に図式的に示されており、図では、複数のユーザ端末にサービスを提供するアクセスポイントとしてＩＰ−ＰＢＸ（「ＩＰ−ＰＢＸ１」および「ＩＰ−ＰＢＸ２」と示されている）を示す。１つの発呼端末は内線１２３４と示され、１つは「内線５６７８」と示されている。第１の端末が第２の端末にセッションを要求している。企業１および２のユーザは、ＩＭＳ内に専用のビジネストランクアプリケーション（ＢＴ−ＡＳ）を有する。このアプリケーションは、特定のサービスを提供するために、発呼／発信加入者または被呼／着信加入者のアイデンティティを有する必要がある。この解決手段は、ユーザに対して公的に利用可能なネットワークベースのＩＭＳサービスを識別するいわゆるパブリック・サービス・アイデンティティ（ＰＳＩ）を利用する。解決手段は、ＨＳＳ内のＩＰ−ＰＢＸに関するサブスクリプションのサービスプロファイルの中に、ＩＰ−ＰＢＸに属する端末に指定されたＰＵＩに合致し、ＩＭＳの特定のアプリケーションへのアクセスを与えるワイルドカード化ＰＳＩを規定する。解決手段は、ユーザ対ユーザセッションのために、ＢＴ−ＡＳとともにＰＳＩを使用して、発呼および被呼の場合に対する次善の手段を提供する。ＩＰ−ＰＢＸ１およびＩＰ−ＰＢＸ２の登録は、ＩＰ−ＰＢＸが自装置のＰＵＩで登録する点において、通常のＵＥの登録と全く同じである。

図３は、発信（発呼）の場合、すなわちＰＢＸ収容の端末が遠隔の端末への呼を開始する場合の次善の解決手段を示す。ＩＰ−ＰＢＸ１は企業１に属し、自装置のＰＵＩとして「ＰＢＸ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」を有する。ＩＰ−ＰＢＸ１は、グループコード８５０を有し、番号の範囲は＋３１−１６１−２４−ＸＸＸＸである。従業員Ａｌｉｃｅは、内線１２３４の自分の端末から、ＩＰ−ＰＢＸ１にグループコード８５１と定められているＩＰ−ＰＢＸ２に収容された内線５６７８の企業２のＢｏｂの端末へのセッション設定を要求する。

Ａｌｉｃｅの要求１０１は、ＩＰ−ＰＢＸ１で受け付けられ、ＩＰ−ＰＢＸ１は、Ｐ−ＣＳＣＦ向けの外線発信要求１０２を組み立てる。メッセージのフォーマットは以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＴｅｌ：＋３１１６１２５５６７８
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：８５１５６７８；ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

受信時、外線発信Ｐ−ＣＳＣＦは、ＩＮＶＩＴＥ内に含まれたＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙを認識しない。このＰ−ＣＳＣＦは、デフォルトのＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙとしてＩＰ−ＰＢＸ１のＰＵＩすなわち「ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」を使用する。ここでＰ−ＣＳＣＦからＳ−ＣＳＣＦに送信されるメッセージ１０３は、以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＴｅｌ：＋３１１６１２５５６７８
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：８５１５６７８；ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｓ−ＣＳＣＦでは、メッセージのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを使用して、ＩＰ−ＰＢＸ１のユーザプロファイルを調べ、Ｓ−ＣＳＣＦにＢＴアプリケーションを参加させるように伝えるＩＦＣを有するサービスプロファイルを見つける。それ故、Ｓ−ＣＳＣＦは、ＢＴアプリケーションで受信されるＩＮＶＩＴＥメッセージ１０４を送信する。ＢＴアプリケーションサーバは、発信ユーザが「Ｆｒｏｍ」ヘッダの中で識別されるユーザであることを立証して主張し、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダを発呼ユーザのアイデンティティすなわち「ｔｅｌ：＋３１１６１２４１２３４」で置き換える。ＢＴアプリケーションは、Ａｌｉｃｅに対する新しいａｓｓｅｒｔｅｄＩＤで変更されたＩＮＶＩＴＥメッセージ１０５を戻す。メッセージは、今度は以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＴｅｌ：＋３１１６１２５５６７８
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：８５１５６７８；ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｓ−ＣＳＣＦに戻って、要求されたＴｅｌＵＲIを周知のＳＩＰＵＲＩに変換するためにＥＮＵＭルックアップ１０６を実行しなければならない。次いで適合されたＩＮＶＩＴＥメッセージ１０７は、オペレータ２のネットワークにさらに伝送されるために、オペレータ１の相互接続ボーダ制御機能（Ｉ−ＢＣＦ、Interconnected Border Control Function）に送信される。最終的に、ＩＮＶＩＴＥメッセージは以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＳＩＰ：＋３１１６１２５５６７８＠ｏｐｅｒａｔｏｒ２．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：８５１５６７８；ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

さらに、図４を参照すると、ＩＮＶＩＴＥメッセージがオペレータ２のＩ−ＢＣＦに到着する。Ｉ−ＢＣＦは、受信したのと同じメッセージ２０１をＩ−ＣＳＣＦに転送する。Ｉ−ＣＳＣＦは、電話番号に相当するＳＩＰ要求ＵＲＩを認識し、これをＴｅｌＵＲＩに変換する。このＡｌｉｃｅからＢｏｂへの接続の例では、ＳＩＰ要求ＵＲＩは、「ｓｉｐ：＋３１１６１２５５６７８＠ｏｐｅｒａｔｏｒ２．ｃｏｍ，ｕｓｅｒ＝ｐｈｏｎｅ」であり、これがＴｅｌＵＲＩ「Ｔｅｌ：＋３１１６１２５５６７８」に変換される。次いでＩ−ＣＳＣＦは、通常のＩＭＳ手順に従って、位置情報要求２０２をＨＳＳに送信する。ＨＳＳは、ＴｅｌＵＲＩがＰＳＩワイルドカードに合致すると判定し、割り当てられたＳ−ＣＳＣＦのアイデンティティを有する位置情報回答２０３でＩ−ＣＳＣＦに応答する。ここでは、少なくとも１つのアプリケーションのサブスクリプションを有している、まだ登録されていない端末に対して使用されるのと同じメカニズムが使用される。Ｉ−ＣＳＣＦは、割り当てられたＳ−ＣＳＣＦにＳＩＰメッセージ２０４を転送する。メッセージは、そのとき以下のように見える。

次にＳ−ＣＳＣＦは、まだ登録されていない端末に対して動作するであろうように動作する。Ｓ−ＣＳＣＦは、ＨＳＳからのワイルドカード化ＰＳＩに合致するサービスプロファイルを少なくとも１つ含むユーザプロファイルをＨＳＳから取得する。このプロファイルは、Ｓ−ＣＳＣＦにメッセージ２０５をビジネストランキングアプリケーションサーバ（ＢＴ−ＡＳ）へ送らせるＩＦＣトリガを含む。アプリケーションサーバは、ＳＩＰ要求ＵＲＩ「Ｔｅｌ：＋３１１６１２５５６７８」をＩＰ−ＰＢＸ２のアドレスすなわち「ｐｂｘ２＠ｏｐｅｒａｔｏｒ２．ｃｏｍ」で置き換え、宛先アドレスをＴｏヘッダフィールドに挿入し、今では失われている前のコンテンツを削除する。戻されたメッセージ２０６は、今では以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＰＢＸ２＠ｏｐｅｒａｔｏｒ２．ｃｏｍ
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｔｅｌ：＋３１１６１２５５６７８
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

今では新しいＵＲＬがＩＮＶＩＴＥ被要求フィールドにあり、要求ＵＲＩが変更され、従って新しい着信者が目標となっているので、Ｓ−ＣＳＣＦは、ＢＴ−ＡＳから受信したのと同じメッセージ２０７をＩ−ＣＳＣＦに転送しなければならない。次いで、メッセージは別のＩ−ＣＳＣＦに到着し、このＩ−ＣＳＣＦは、ＨＳＳに位置情報要求２０８を行い、ＩＰ−ＰＢＸ２に割り当てられたそのＳ−ＣＳＣＦを確認してから、その割り当てられたＳ−ＣＳＣＦにメッセージを配信する。ＨＳＳは、位置情報回答２０９を与え、Ｉ−ＣＳＣＦは、ＩＮＶＩＴＥメッセージ２１０をＳ−ＣＳＣＦに転送する。

ＩＰ−ＰＢＸ２はたいがい既に登録されているので、Ｓ−ＣＳＣＦはＩＰ−ＰＢＸ２の連絡アドレスを知っている。ＩＰ−ＰＢＸ２用のＰ−ＣＳＣＦにＩＮＶＩＴＥ要求を送信する前に、まずＩＰ−ＰＢＸ２に関するユーザプロファイルのサービスプロファイルの中のｉＦＣが、オプションとしてメッセージ２１１および戻りのメッセージ２１２によって示されるさらなるＩＭＳアプリケーションをトリガするために調べられる。トリガがないときかまたは最後のアプリケーションの応答後、Ｓ−ＣＳＣＦは、新しい被要求ＵＲＩとしてＩＰ−ＰＢＸ２の連絡アドレスを加える。古いＵＲＩ「ｐｂｘ２＠ｏｐｅｒａｔｏｒ２．ｃｏｍ」を保存するために、Ｓ−ＣＳＣＦは、このＵＲＩを含むＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤを加える。Ｐ−ＣＳＣＦに転送されたメッセージ２１３は、今は以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＰＢＸ２−ｃｏｎｔａｃｔ−ａｄｄｒｅｓｓ
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｔｅｌ：＋３１１６１２５５６７８
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤ：ＰＢＸ２＠ｏｐｅｒａｔｏｒ２．ｃｏｍ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｐ−ＣＳＣＦは、ＩＮＶＩＴＥヘッダで指示されたように、メッセージ２１４をＩＰ−ＰＢＸ２に転送する。ＩＰ−ＰＢＸ２は、企業２の企業ネットワークを通してＢｏｂの端末への接続設定を担当する。宛先端末がＳＩＰ端末である場合は、ＩＰ−ＰＢＸ２は、メッセージの受信時、「Ｔｏ」ヘッダフィールドに含まれたアドレスに基づき端末へメッセージを配信するように手配できる。宛先端末がＳＩＰ端末でない場合、ＩＰ−ＰＢＸ２端末は、何らかのアプリケーション固有ロジックに従って着信処理をすることになる。

図２に示される「次善の」解決手段には、ＣＳＣＦ集合物の２回の横断を必要とするという欠点がある。これは、メッセージ通過時間の増加をもたらすであろう。さらに、元々「Ｔｏ」ヘッダに含まれていた情報が、発呼者によって挿入された元の要求ＵＲＩが失われたのと同じように、失われる。元の「Ｔｏ」ヘッダなしでは、被呼端末の特定のアプリケーションは機能しないことがある。さらに次善の手段では、正しいＰ−Ａｓｓｅｒｔｅｄ−ＩＤを作成できるためには、ＢＴアプリケーションまたは類似の機能を有するものが利用可能でなければならないことを必要とする。

この次善の手段で前提としたＩＰ−ＰＢＸの代わりに、会社は、ＳＩＰ対応移動端末に対して標準ＲＦＣ３２６１ＳＩＰプロキシサーバを使用してもよい。この場合も同様に、会社は、個別のサブスクリプションではなくＩＭＳへのグループサブスクリプションを有してもよい。ＳＩＰプロキシサーバに関する基本動作は、着信呼の場合に被要求ＵＲＩがＳＩＰプロキシサーバのアドレスを含むはずであるから、ＩＰ−ＰＢＸの基本動作と全く同じである。「Ｔｏ」ヘッダから最終の宛先を読み出すのは、ＳＩＰプロキシサーバである。

上記の次善の手段の主な問題は、グループサブスクリプションの場合に、元の被要求ＵＲＩが、ＩＰ−ＰＢＸまたはＳＩＰプロキシサーバのアドレスで置き換えられることである。ＩＮＶＩＴＥメッセージを最終宛先まで経路選定できるためには、ＲＦＣ３２６１標準に準拠して動作するＩＰ−ＰＢＸまたはＳＩＰプロキシサーバに変更が必要である。その理由は、この標準は、最終宛先が被要求ＵＲＩであると予想しているからである。

特定の場合に対して予備手段を計画することは可能であろうが、これは、より本質的な問題も持ち込む。ＩＭＳのノードを適合させるとき、ノードは、対処を必要とするユーザと標準的なやり方で処理できるので対処を必要としないユーザとの両方を処理できなければならない。ノードを専用のユーザグループ固有にすることはできるが、運用の観点からは望ましくない。

３ＧＰＰＴＳ２２．２２８ＩＥＴＦＲＦＣ２４８６３ＧＰＰＴＳ２３．２２８ＩＥＴＦＲＦＣ３２６１ＩＥＴＦＲＦＣ２３９６ＩＥＴＦＲＦＣ３９６６３ＧＰＰＴＳ３３．２０３ＩＥＴＦＲＦＣ３３２９「ＩＭＳ（ＴｈｅＩＭＳ）」、ＩＳＢＮ９７８−０−４７０−０１９０６−１

本発明の主な目的は、ＩＰマルチメディアサブシステムの機能を特定のユーザカテゴリに対して適合できるようにする方法、システムおよびノードを提供することである。

この目的は、ＩＭＳサブスクリプションのユーザに対してノードの標準機能を変更するために、ＩＭＳサブスクリプションにＩＰマルチメディアサブシステムのノードに対する機能指示を加えることで達成される。オプションとして、サブスクリプションがそのような機能指示を含むことを示すために、サブスクリプションはさらにＩＰマルチメディアサブシステムのノードに対するインジケータを含む。

本明細書は、様々なタイプの機能指示をさらに開示する。

さらなる態様として、本明細書は、サブスクリプションを１つだけ有し、サブスクリプションの中の機能指示を利用するＲＦＣ３２６１標準の企業ＩＰ−ＰＢＸまたはＳＩＰプロキシサーバに収容されたユーザにサービスを提供するときに、着信ＩＮＶＩＴＥ要求の中の被要求ＵＲＩを保持する問題に対して改善された解決手段を開示する。改善された解決手段は、Ｓ−ＣＳＣＦに対して、被要求ＵＲＩをＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−Ｉｄｅｎｔｉｔｙヘッダにコピーし、被要求ＵＲＩをアクセスポイントの連絡アドレスで置き換える指示を備える。

この改善された解決手段は、第１の事例では、ＩＭＳ内のＩＰ−ＰＢＸやＳＩＰプロキシサーバのような分離非ＩＭＳネットワークのアクセスポイントの登録の変更で達成され、アクセスポイントによって受信されるメッセージヘッダが分離非ＩＭＳネットワーク内のメッセージの最終宛先に関してどのようにフォーマットされるかについての情報をサブスクリプションが含むか、またはこの情報は登録手順中にアクセスポイントからＩＭＳに提供される情報要素の中に含まれる。

第２の事例では、この改善された解決手段は、ＩＭＳとアクセスポイントとの間のプロトコルの変更で達成され、このプロトコル変更は、変更された登録手順の中でユーザプロファイルによって提供される機能指示によって、分離非ＩＭＳネットワークを通して最終宛先への以降の伝送のために、ＩＭＳからアクセスポイントへ送信されるメッセージに関する。

第３の事例では、この改善された解決手段は、サブスクリプションに関連づけられた暗黙的な登録セット内にワイルドカード化パブリック・ユーザ・アイデンティティを含めることによって達成される。「ワイルドカード化」または「ワイルドカード」は、１つ以上の指定されていない文字を意味する１つ以上のシンボルを含むパブリック・ユーザ・アイデンティティを意味するとここでは理解される。ワイルドカード化パブリック・ユーザ・アイデンティティは、それに関連づけられたサービスプロファイルを有するであろう。暗黙的な登録セットに基づきチェックまたは処理を実行するＩＰマルチメディアサブシステム内のどのノードも、受信したパブリック・ユーザ・アイデンティティが暗黙的な登録セット内の任意の標準パブリック・ユーザ・アイデンティティに合致した場合と同じやり方で、ワイルドカード化パブリック・ユーザ・アイデンティティに合致する受信したパブリック・ユーザ・アイデンティティに関して実行することになる。ワイルドカード化パブリック・ユーザ・アイデンティティを用いてパブリック・ユーザ・アイデンティティの範囲を表すのでなく、そのような範囲を代わりにサブドメインで表わしてもよい。例えば、ＴｅｌＵＲＩの範囲を、電話番号のプレフィックスによって表わしてもよいのに対して、ＳＩＰＵＲＩの範囲を企業ドメインによって表わしてもよい。

３つの全事例の特徴となっているのは、ＩＭＳノードに対してそれらの機能の標準的なやり方をこの代替のやり方に変更する指示がサブスクリプションに含まれていることである。さらなるオプションとして、サブスクリプションは、このサブスクリプションを有するユーザ装置またはアクセスノードの登録時に、サブスクリプションの特定の要素の更新を可能にする特別の指示を含んでもよい。

本発明の別の態様によれば、ＩＰマルチメディアサブシステムネットワークへのアクセスポイントに収容されたユーザ端末から、このネットワークのサービスへのアクセスを促進する方法が提供される。アクセスポイントは、ＩＰマルチメディアサブシステムネットワークのサブスクリプションに関連づけられている。方法は、ワイルドカード化パブリック・ユーザ・アイデンティティまたはパブリック・ユーザ・アイデンティティの範囲を表すパブリック・ユーザ・アイデンティティ・サブドメインをこのサブスクリプションに関して定められた暗黙的な登録セット内に含める工程を備える。このアクセスポイントのＩＰマルチメディアサブシステムネットワークへのＩＰマルチメディアサブシステム登録時、暗黙的な登録セットの中に含まれるパブリック・ユーザ・アイデンティティまたは登録要求メッセージ内の特別情報要素の中で提供されるパブリック・ユーザ・アイデンティティが、このアクセスポイントに割り当てられたサービング呼セッション制御機能およびこのアクセスポイントが接続しているプロキシ呼セッション制御機能に配信される。

本発明の実施形態は、企業ネットワークまたは同種のネットワーク内に配置されたユーザ端末で、かつ端末自体にＩＰマルチメディアサブシステムサブスクリプションがないユーザ端末に、直通ダイヤルの外線着信および外線発信を含むＩＰマルチメディアサブシステムサービスを提供することを可能にする。シグナリングに関して追加のＳ−ＣＳＣＦ集合物の横断は必要なく、重要なＳＩＰヘッダ情報は保存される。

本発明のさらなる態様は、サービング呼セッション制御機能、プロキシ呼セッション制御機能、ホーム加入者サーバ、およびそれらの動作方法に関する。

本発明のまた別の態様によれば、ＩＰマルチメディアサブシステムのホーム加入者サーバの動作方法が提供される。方法は、サブスクリプションまたはサービスに関して、ワイルドカード化パブリック・サービス・アイデンティティもしくは１つ以上のサービスに関連づけられたパブリック・サービス・アイデンティティの範囲を表すパブリック・サービス・アイデンティティ・サブドメインと、アクセスポイントに収容されたユーザ端末への以降の伝送のためにアクセスポイントに送信されるメッセージのヘッダをフォーマットするルールセットと、これらのサービスに割り当てられたサービング呼セッション制御機能のアイデンティティもしくはサービング呼セッション制御機能を割り当てる基準とを維持する工程を備える。インテロゲーティング呼セッション制御機能が受信したＳＩＰメッセージに関して、インテロゲーティング呼セッション制御機能から位置情報要求の受信時、メッセージの要求ＵＲＩが前述のワイルドカード化パブリック・サービス・アイデンティティまたはサブドメインに合致する場合、インテロゲーティング呼セッション制御機能は、サービング呼セッション制御機能のアイデンティティを通知されるか、または選択基準を提供される。

本発明のさらなる態様は、デジタルコンピュータの内蔵メモリに読み込み可能なコンピュータプログラム製品で、かつホーム加入者サーバの上記動作方法のステップを実行するためのソフトウェアコード部分を備えるコンピュータプログラム製品を提供する。さらなる態様は、デジタルコンピュータの内蔵メモリに読み込み可能なコンピュータプログラム製品で、かつ本発明に従ってサービング呼セッション制御機能、プロキシ呼セッション制御機能およびインテロゲーティング呼セッション制御機能の動作ステップを実行するためのソフトウェアコード部を備えるコンピュータプログラム製品を提供する。

先行技術によるユーザのＩＭＳサブスクリプションとパブリック・ユーザ・アイデンティティとプライベート・ユーザ・アイデンティティとの間の関係例を図式的に示す図である。先行技術によるＩＭＳの標準登録手順を図式的に示す図である。先行技術によるＩＭＳアーキテクチャ内の発信呼の場合の先行技術の次善の解決手段を図式的に示す図である。先行技術によるＩＭＳアーキテクチャ内の着信呼の場合の先行技術の次善の解決手段を図式的に示す図である。本発明の一実施形態による、ＩＰ−ＰＢＸに関する登録シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。本発明の一実施形態による、ＳＩＰプロキシに関する登録シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。ＳＩＰプロキシに関する、登録ベースの更新を行う登録シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。発信ＴｅｌＵＲＩに基づく本発明の一実施形態による、ＩＰ−ＰＢＸに関する発信シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。発信ＳＩＰ−ＵＲＩに基づく本発明の一実施形態による、ＩＰ−ＰＢＸに関する発信シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。本発明の一実施形態による、ＩＰ−ＰＢＸに接続され、かつＴｅｌＵＲＩでアドレス指定されたユーザに関する、着信シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。本発明の一実施形態による、ＳＩＰプロキシに接続され、かつＳＩＰＵＲＩでアドレス指定されたユーザに関する、着信シグナリングフローを有するＩＭＳアーキテクチャを図式的に示す図である。

説明する解決手段および実施形態は、ＩＭＳ内のノードが、自装置の機能をより柔軟に実行して、１つだけのユーザグループに固有でなく、異なる処理を必要とするユーザのグループにサービスを提供できるＩＭＳを提供する。

そのようなユーザグループの例は、アクセスポイントを介してＩＭＳに接続されたユーザグループである。アクセスポイントがサブスクリプションを１つだけ有し、１つの登録だけを必要とするが、個別のユーザはＩＭＳ内で個別に識別可能である。これを考慮すると、アクセスポイントは、それが代表するグループのために登録行為を実行するやはりアクセスポイントであるので、多種類のアクセスポイントとともに働くことができるように、ＩＭＳは融通性が利かなければならない。サブスクリプションを１つだけ有するグループは、ＩＭＳのノードの異なる処理を必要とするサブスクリプションの一例に過ぎない。他の例は、サブスクリプションを持たない他のネットワーク内の端末に一時的に割り当てられるサブスクリプション、またはＩＭＳサブスクリプションを有するがそのユーザの端末がＩＭＳへ別の非ＩＭＳネットワークを介して接続されているユーザである。

ＩＭＳのノードに対する機能指示をサブスクリプション内に含めることによって、または機能指示を登録時に設定可能にすることによって、必要な融通性を提供できる。機能指示は、そのサブスクリプションに関連づけられた特定のユーザグループに対してＩＭＳノードの標準機能を変更する。

アクセスポイントに対するＩＭＳの実際の動作は、遅くとも登録時に決定されなければならない。その時まで、ＩＭＳは、ＵＥに依存しない（標準）動作を有してもよい。他方では、ＩＭＳ内の全ＣＳＣＦノードおよびＨＳＳのような他のノードは、特別の機能だけを実行するようには作られないものとする。それらのノードは、特別のＵＲＩだけにサービスを提供するのではなく、その時点でサービスを受けているＵＲＩに動作を適合させるものとする。こうすることにより、ＩＭＳの至る所で負荷のバランスを取れる可能性を維持することになる。

登録時に決定されるノードの代替機能の詳細例について、３つの登録状況、２つの発信／発呼状況および２つの着信／被呼状況を用いて説明する。

第１の登録状況は図５に概要が示されており、ＰＢＸであるＩＰ−ＰＢＸ１がグループの端末を代表して登録する。ＩＰ−ＰＢＸ１自体のアイデンティティは「ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」である。代理されたグループの番号の範囲は、＋３１−１６１−２４−ＸＸＸＸである。図５のメッセージ番号は、図２のメッセージ番号と一致する。メッセージシーケンスは全く同じであり、ＩＰ−ＰＢＸは、図２のＵＥと同じやり方で登録する。主な違いは、ＩＭＳを通常のＵＥに対するのとは異なって動作させる要素を今度はサブスクリプションが含むことである。第１の違いは、通常のＰＵＩの代わりに、今度はＩＰ−ＰＢＸ１に関するＨＳＳ内のサブスクリプションがＩＰ−ＰＢＸ１自体のＵＲＩに加えてワイルドカードＰＵＩを含むことである。この特定の場合では、ワイルドカードＵＲＩは、ＴｅｌＵＲＩ；「ｔｅｌ：＋３１１６１２４！＊！」であり、シンボルシーケンス！＊！は、４桁の任意の数を示す。ワイルドカードに合致するどのＴｅｌＵＲＩも、ＩＰ−ＰＢＸ１がその主なＰＵＩである「ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」で登録すると、暗黙的に登録される。ワイルドカードＵＲＩを１つだけの使用する代わりに、番号の下位範囲も、ワイルドカードなしのＴｅｌＵＲＩと組み合わせて使用されてもよい。これは、異なる下位範囲または専用番号に対して異なるサービスプロファイルの使用を可能にするであろう。しかし、どの合致するＵＲＩも常に関連づけられたサービスプロファイルを１つだけ有するように配慮されなければならない。暗黙的な登録によって、ＩＭＳによるＩＰ−ＰＢＸ１に収容された端末の確認が今では容易になっているが、ＩＭＳからのメッセージはやはりＩＰ−ＰＢＸを通過し、ＩＰ−ＰＢＸはそれらを端末に渡すであろう。これには、企業ネットワークの制約によるメッセージの変更を含んでもよい。ＳＩＰメッセージ使用の主な手順は変わらなくてもよいが、フィールドの値は、ＩＭＳの基本動作が危険にさらされない範囲でＩＰ−ＰＢＸ１のニーズに適応させるために変更されてもよい。実際には、ＲＥＧＩＳＴＥＲメッセージが除かれるので、そのような変更はＰ−ＣＳＣＦおよびＳ−ＣＳＣＦに限定されるであろう。ルールセットを用いた実施方法の詳細は、詳細説明の最後に記述する。

第２の登録状況は、図６に示されている。これでは、企業ＳＩＰプロキシサーバが、企業ネットワークを介してそれに接続されたＳＩＰ端末を代表して登録する。ＳＩＰ端末に関するＵＲＩの範囲は、「ＸＸＸＸＸＸＸＸ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ」である。ＳＩＰプロキシサーバ自体のＰＵＩは、「ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」である。プロキシサーバは、ＲＦＣ３２６１標準サーバでもよいし、また企業ネットワークのニーズに特別に適合されてもよい。この場合も同様に登録は、通常のＵＥの登録と全く同等である。プロキシサーバは、自装置をＵＥのように登録する。図６のメッセージ番号は、図２および５のメッセージ番号と一致する。この場合も同様に、違いはサブスクリプションにある。ＩＰ−ＰＢＸに関しては、サブスクリプションは、プロキシサーバ自体のＰＵＩは別にして、ワイルドカードＰＵＩも含む。一般形態では、これは、「！＃！＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ」のように見えてもよいＳＩＰＵＲＩワイルドカードである。シンボル！＃！は、英数文字のストリングを示す。この場合も同様に、ワイルドカードＳＩＰＵＲＩに合致するどのＳＩＰＵＲＩも、プロキシサーバ自体が登録するとき、暗黙的に登録される。

ここでも同様に、異なるサービスプロファイルに関連づけることが可能なワイルドカード化ＳＩＰＵＲＩと非ワイルドカード化ＳＩＰＵＲＩとの組み合わせを与える英数字の下位範囲が使用されてもよい。良い一例は、ＩＭＳアプリケーションのパラメータを設定できる非ワイルドカード化ＳＩＰＵＲＩの特別ｉＦＣを有するアドミニストレータの下位範囲である。言及されていないが、同様に図５に関係して前述のように、ワイルドカード化または非ワイルドカード化ＴｅｌＵＲＩが加えられてもよい。

第３の登録状況が図７に示されている。ここでは、企業ＳＩＰプロキシサーバは、企業ネットワークを介してそれに接続されたＳＩＰ端末を代表して登録する。ＳＩＰ端末に関するＵＲＩの範囲は「ＸＸＸＸＸＸＸＸ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ」である。ＳＩＰプロキシサーバ自体のＰＵＩは、「ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」である。プロキシサーバは、ＲＦＣ３２６１標準サーバでもよいし、また企業ネットワークのニーズに特別に適合されてもよい。この場合も同様に、登録は、通常のＵＥの登録と全く同等である。プロキシサーバは、自装置をＵＥのように登録する。図７のメッセージ番号は、図２、５、６のメッセージ番号と一致する。異なるメッセージは添え字「ａ」を有する。

第１および第２の登録状況では、動作制御要素はサブスクリプションに含まれていた。第３の状況では、それらは当初サブスクリプションに含まれていてもよいが、登録中にアクセスノードここではＳＩＰプロキシサーバが、サブスクリプションの値を上書きする要素の最新セットを提供する。これは、例えば企業１のアドミニストレータ機能が別の人に変更になるとき有利な、固有のものであってもよい。アドミニストレータ機能を実行する新しい人に対して特別のサービスプロファイルを維持するために、この場合、サブスクリプションの変更は必要ない。特に大会社では、職務変更は非常に頻繁であろう。

プロファイルはＳ−ＣＳＣＦで更新されるが、ＨＳＳは被呼／着信の場合にＩ−ＣＳＣＦから質問される。このため、端末がアクセスポイントからサービスを受けていることを確認でき、それに対して適切なＳ−ＣＳＣＦを割り当てできる少なくとも最大のワイルドカードＰＵＩをＨＳＳは含むことが必要である。

更新は、完全なユーザプロファイルの形態またはユーザプロファイルの特定の要素を有してもよい。より詳細な例については、詳細説明の最後に示す。更新情報は、ＳＩＰ登録メッセージに含まれなければならない。以下に、更新情報がＣｏｎｔａｃｔフィールドに含まれる例を示す。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＲＥＧＩＳＴＥＲｓｉｐ：ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｖｉａ：＜ｃｕｒｒｅｎｔＩＰｐｂｘ１＞；
Ｒｏｕｔｅ：＜ｃｕｒｒｅｎｔＩＰａｄｄｒｅｓｓｏｆＰ−ＣＳＣＦ＞
Ｍａｘ−Ｆｏｒｗａｒｄｓ：５０
Ｆｒｏｍ：ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｔｏ：ｐｂｘ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ
Ｃｏｎｔａｃｔ：＜ｃｕｒｒｅｎｔＩＰｐｂｘ１＞；ｅｘｐｉｒｅｓ＝２０００；ｕｐｄａｔｅ＝＜ｕｐｄａｔｅｉｎｆｏｒｍａｔｉｏｎ＞
Ｃａｌｌ−ＩＤ：ｇｒｔ３８ｕ６ｙｑｒ５４ｇｆｋｐ９８ｙ６ｔ３ｒｒ
ＣＳｅｑ：２５ＲＥＧＩＳＴＥＲ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：０
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｃｏｎｔａｃｔフィールドだけが、通常の登録用のメッセージフォーマットと異なることに注意されたい。ＣｏｎｔａｃｔフィールドはＳ−ＣＳＣＦ向けのフローを通じて維持されるので、メッセージ２ａ、５ａ、１２ａ、１５ａはＣｏｎｔａｃｔフィールドに同じ追加物を有する。Ｓ−ＣＳＣＦは、Ｃｏｎｔａｃｔフィールドの中の「ｕｐｄａｔｅ＝」を認識し、更新を実行するように特に構成される。ＵＥの中には更新を行なうことをオペレータが望まないＵＥがあるので、Ｓ−ＣＳＣＦの更新機能を可能にする指示が、サブスクリプションに加えられてもよい。Ｓ−ＣＳＣＦは、ＨＳＳから取得したユーザプロファイルを更新情報で更新する。これは、主なＰＵＩのＩＭＳサービスへの登録の前に、メッセージ２１、２２で行われる。再登録時に追加の更新を許容し、これにＳ−ＣＳＣＦを適合させるのもオペレータポリシーである。

登録手順の中にＰＢＸまたはＳＩＰプロキシサーバが示されているところでは、同様に他のどのタイプのアクセスポイントと読み取られてもよい。グループサブスクリプションの基本的登録方法は、すべてのタイプのアクセスポイントに対して全く同じである。ＰＢＸまたはＳＩＰプロキシサーバが自装置の登録を実行する代わりに、登録をＰＢＸまたはＳＩＰプロキシサーバに代わって登録する機能によって行うことができよう。このような機能は、例えばシグナリング・ボーダ・ゲートウェイなどのボーダノードの中に配置できよう。ボーダノードはＰＢＸもしくはＳＩＰプロキシサーバとＰ−ＣＳＣＦとの間に配置されてもよいし、Ｐ−ＣＳＣＦを含んでもよい。登録機能を収容できるデバイスの別の例には、顧客宅の統合アクセスデバイスまたはホームゲートウェイがある。

本発明による第１の発信／発呼の事例が、図８に示されている。メッセージ番号は、図３に示される次善の手段のメッセージと全く同じであるが、但し大幅な相違があるところだけには、添え字「ａ」がメッセージ番号に付加されている。ＩＰ−ＰＢＸ１は企業１に属し、自装置のＰＵＩとして「ＰＢＸ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」を有する。ＩＰ−ＰＢＸ１は、グループコードとして８５０および番号範囲として＋３１−１６１−２４−ＸＸＸＸを有する。従業員Ａｌｉｃｅが、内線１２３４の自分の端末から、ＩＰ−ＰＢＸ１にグループコード８５１と定められているＩＰ−ＰＢＸ２に収容された内線５６７８を有する企業２のＢｏｂの端末へのセッション設定を要求する。

Ａｌｉｃｅの要求１０１は、Ｐ−ＣＳＣＦ向けの外線発信要求１０２を組み立てるＩＰ−ＰＢＸ１で受け付けられる。メッセージのフォーマットは、以下のように見える。

今や外線向けのＰ−ＣＳＣＦによって受信されると、Ｐ−ＣＳＣＦは、ＩＮＶＩＴＥ内に含まれたＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙを、ワイルドカードＰＵＩを含む暗黙的な登録セットに基づき認識する。Ｐ−ＣＳＣＦは、ここでＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙと全く同じくＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを設定する。Ｐ−ＣＳＣＦからＳ−ＣＳＣＦにここで送信されるメッセージ１０３ａは、以下のように見える。

Ｓ−ＣＳＣＦでは、メッセージのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを使用して、ＰＵＩとしてＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙのＴｅｌＵＲＩを有するユーザプロファイルを調べる。Ｓ−ＣＳＣＦは、ＡｌｉｃｅのＰＵＩに関連づけられたサービスプロファイルに属するｉＦＣによって指示されたように、やはりＢＴ−ＡＳに進むかもしれないが、Ａｌｉｃｅに関する正しいＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを取得するためには、これはもはや必要ない。初期フィルタ基準は、ノードの機能を制御する意味では指示と間違えられないことになっている。初期フィルタ基準は、ＩＭＳサービスがユーザに行われてもよいか、行われなくてもよいかを選択することを改めるだけである。いずれにせよＢＴ−ＡＳに進むための理由例は、ＩＰ−ＰＢＸ１状況による番号の代わりに、ＦｒｏｍフィールドおよびＴｏフィールドをＡｌｉｃｅおよびＢｏｂの完全なＴｅｌＵＲＩに変換するためである。

Ｓ−ＣＳＣＦに戻って、要求されたＴｅｌＵＲＩを周知のＳＩＰＵＲＩに変換するためにはＥＮＵＭルックアップ１０６を実行しなければならない。次いで適合されたＩＮＶＩＴＥメッセージ１０７は、オペレータ２のネットワークにさらに伝送されるために、オペレータ１の相互接続ボーダ制御機能（Ｉ−ＢＣＦ）に送信される。最終的にＩＮＶＩＴＥメッセージは、以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＳＩＰ：＋３１１６１２５５６７８＠ｏｐｅｒａｔｏｒ２．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：＋３１１６１２４１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：＋３１１６１２５５６７８＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

本発明による第２の発信／発呼の事例が、図９に示されている。メッセージ番号は図３に示される次善の手段のメッセージと全く同じであるが、但し大幅な相違があるところだけには、添え字「ｂ」がメッセージ番号に付加されている。ＳＩＰプロキシサーバは、企業１に属し、自装置のＰＵＩとして「ＰＢＸ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」を有する。ＳＩＰプロキシサーバは、ＳＩＰＵＲＩの範囲「！＃！＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ」を代表して動作する。従業員Ａｌｉｃｅが、ＳＩＰＵＲＩとしてａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍを有する自分の端末から、企業２のＳＩＰプロキシサーバによって処理されＳＩＰＵＲＩとして「ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ」を有する企業２のＢｏｂの端末へのセッション設定を要求する。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＳＩＰ：ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ
Ｆｒｏｍ：Ａｌｉｃｅ＜ａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｔｏ：Ｂｏｂ＜ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ＞
Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙ：ａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

この場合も同様に、外線発信用のＰ−ＣＳＣＦによって受信されると、ＩＮＶＩＴＥ内に収容されたＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙを、ワイルドカードＰＵＩを含む暗黙的な登録セットに基づき認識する。Ｐ−ＣＳＣＦは、ここでＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙと全く同じくＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを設定する。Ｐ−ＣＳＣＦからＳ−ＣＳＣＦにここで送信されるメッセージ１０３ａは、以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＳＩＰ：ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ
Ｆｒｏｍ：Ａｌｉｃｅ＜ａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｔｏ：Ｂｏｂ＜ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：ａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｓ−ＣＳＣＦでは、メッセージのＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを使用して、ＰＵＩとしてＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙのＳＩＰ−ＵＲＩを有するユーザプロファイルを調べる。Ｓ−ＣＳＣＦは、ＡｌｉｃｅのＰＵＩに関連づけられたサービスプロファイルに属するｉＦＣによって指示されたように、やはりＸＸ−ＡＳに進むかもしれないが、Ａｌｉｃｅに関する正しいＰ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙを取得するためには、これはもはや必要ない。呼設定が、通常の手順に従って続く。要求ＵＲＩ、Ｆｒｏｍ、Ｔｏ、Ｐ−Ａｓｓｅｒｔｅｄ−ＩＤのヘッダは、グループ処理操作で変更されない（通常の非グループユーザに対して行われるやり方とは異なるやり方では、少なくとも変更されない）ことが分かるであろう。Ｓ−ＣＳＣＦに戻って、オペレータ２のネットワークにさらに伝送するために、ＩＮＶＩＴＥメッセージ１０７をオペレータ１の相互接続ボーダ制御機能（Ｉ−ＢＣＦ）に転送する。最終的にＩＮＶＩＴＥメッセージは以下のように見える。

本発明による第１の被呼／着信の事例が、図１０に示されている。メッセージ番号は、図４に示される次善の手段のメッセージと全く同じである。ＩＰ−ＰＢＸ１は、企業１に属し、自装置のＰＵＩとして「ＰＢＸ１＠ｏｐｅｒａｔｏｒ１．ｃｏｍ」を有する。ＩＰ−ＰＢＸ１は、グループコードとして８５０を有し、番号の範囲として＋３１−１６１−２４−ＸＸＸＸを有する。従業員Ａｌｉｃｅが、内線１２３４の自分の端末から、ＩＰ−ＰＢＸ１にグループコード８５１と定められているＩＰ−ＰＢＸ２に収容された内線５６７８を有する企業２のＢｏｂの端末へのセッション設定を要求する。ＩＮＶＩＴＥメッセージがオペレータ２のＩ−ＢＣＦに到着し、Ｉ−ＢＣＦは、メッセージ２０１をＩ−ＣＳＣＦに転送する。メッセージは以下のように見える。

Ｉ−ＣＳＣＦは、電話番号に相当するＳＩＰ要求ＵＲＩを認識し、これをＴｅｌＵＲＩに変換する。このＡｌｉｃｅからＢｏｂへの接続例では、ＳＩＰ要求ＵＲＩは、「ｓｉｐ：＋３１１６１２５５６７８＠ｏｐｅｒａｔｏｒ２．ｃｏｍ，ｕｓｅｒ＝ｐｈｏｎｅ」であり、これがＴｅｌＵＲＩ「Ｔｅｌ：＋３１１６１２５５６７８」に変換される。次いでＩ−ＣＳＣＦは、通常のＩＭＳ手順に従って、位置情報要求２０２をＨＳＳに送信する。ここでＨＳＳは、ＴｅｌＵＲＩがＰＵＩワイルドカードに合致すると判定し、割り当てられたＳ−ＣＳＣＦのアイデンティティを有する位置情報回答２０３でＩ−ＣＳＣＦに応答する。Ｉ−ＣＳＣＦは、ＳＩＰメッセージ２０４を割り当てられたＳ−ＣＳＣＦに転送する。そのとき、メッセージは以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＴｅｌ：＋３１１６１２５５６７８
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：＋３１１６１２５５６７８＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

次にＳ−ＣＳＣＦは、通常の登録端末に対して動作するであろうように動作する。Ｓ−ＣＳＣＦは、被要求ＴｅｌＵＲＩをワイルドカードＵＲＩに合致するＴｅｌＵＲＩとして認識する。ユーザプロファイルはＳ−ＣＳＣＦで利用可能である。原則として、Ｓ−ＣＳＣＦはまずＢＴ−ＡＳを経由してから進む必要なしにＰ−ＣＳＣＦに直接転送できる。プロファイルがＩＭＳアプリケーションに対するｉＦＣトリガを含むとき、Ｓ−ＣＳＣＦは、必要に応じてやはりＩＭＳアプリケーション経由で進んでもよい。この例として、Ｂｏｂの外線番号フォーマットのＩＰ−ＰＢＸ２の企業番号フォーマットへの変換がある。トリガがないとき、または最後のアプリケーションの応答後、Ｓ−ＣＳＣＦは、メッセージを関連するＰ−ＣＳＣＦに転送してもよい。通常ＩＮＶＩＴＥヘッダは、ＵＥのＵＲＩを含むであろう。ＩＰ−ＰＢＸ２が端末への配信を担当するので、ここでＩＰ−ＰＢＸ２がアドレス指定されなければならない。Ｓ−ＣＳＣＦは、ＩＰ−ＰＢＸ２のユーザプロファイル内の特別の情報によって指示されたように、その通常の動作を変更する。それ故、ＩＰ−ＰＢＸ２に対する連絡アドレスを新しい被要求ＵＲＩとして加える。古いＵＲＩを保存するために、Ｓ−ＣＳＣＦはこのＵＲＩを含むＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤを付加する。Ｐ−ＣＳＣＦに転送されるメッセージ２１３は、今は以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＰＢＸ２−ｃｏｎｔａｃｔ−ａｄｄｒｅｓｓ
Ｆｒｏｍ：Ａｌｉｃｅ＜Ｔｅｌ：８５０１２３４＞
Ｔｏ：Ｂｏｂ＜Ｔｅｌ：＋８５１５６７８＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：Ｔｅｌ：＋３１１６１２４１２３４
Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤ：Ｔｅｌ：＋３１１６１２５５６７８
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｐ−ＣＳＣＦは、ＩＮＶＩＴＥヘッダによって指示されたように、ＩＰ−ＰＢＸ２にメッセージ２１４を転送する。ＩＰ−ＰＢＸ２は、企業２の企業ネットワークを通してＢｏｂの端末への接続設定を担当する。宛先端末がＳＩＰ端末の場合、メッセージの受信時、ＩＰ−ＰＢＸ２は、「Ｔｏ」ヘッダフィールドに含まれるアドレスに基づき、端末へのメッセージ配信の用意ができる。宛先端末がＳＩＰ端末でない場合、ＩＰ−ＰＢＸ２端末は、何らかのアプリケーション固有のロジックに従って着信処理をするであろう。

本発明による第２の被呼／着信の事例が、図１１に示されている。メッセージ番号は、図４に示される次善の手段のメッセージと全く同じである。ＩＮＶＩＴＥメッセージがオペレータ２のＩ−ＢＣＦに到着する。ＴｅｌＵＲＩの代わりに、メッセージは、今度はＳＩＰＵＲＩを含んでいる。ＩＮＶＩＴＥはやはりＡｌｉｃｅからＢｏｂであるが、ただＢｏｂは、今は企業２のＳＩＰプロキシサーバに収容されている。Ｉ−ＢＣＦは、メッセージ２０１をＩ−ＣＳＣＦに転送する。メッセージは以下のように見える。

この場合も同様に、Ｉ−ＣＳＣＦがＩＮＶＩＴＥメッセージを受信し、ＨＳＳに質問する。ＨＳＳは、ワイルドカードＰＵＩへの計算を認識し、アプローチに対して正しいＳ−ＣＳＣＦを戻す。Ｉ−ＣＳＣＦは、第１の被呼／着信の事例の電話状況に関しては変換を必要としない。Ｉ−ＣＳＣＦは、メッセージ２０４をＳ−ＣＳＣＦへ直接転送する。

次に、Ｓ−ＣＳＣＦは、通常の登録端末に対して動作するであろうように動作する。Ｓ−ＣＳＣＦは、被要求ＴｅｌＵＲＩをワイルドカードＵＲＩに合致するＴｅｌＵＲＩとして認識する。ユーザプロファイルは、Ｓ−ＣＳＣＦで利用可能である。原則として、Ｓ−ＣＳＣＦは、まずＢＴ−ＡＳを経由してから進む必要なしに、Ｐ−ＣＳＣＦに直接転送できる。プロファイルがＩＭＳアプリケーションに対するＩＦＣトリガを含むとき、Ｓ−ＣＳＣＦは、必要に応じてやはりＩＭＳアプリケーション経由で進んでもよい。トリガがないとき、または最後のアプリケーションの応答後、Ｓ−ＣＳＣＦは、メッセージを関連するＰ−ＣＳＣＦに転送してもよい。通常ＩＮＶＩＴＥヘッダは、ＵＥのＵＲＩ含むであろう。ＳＩＰプロキシサーバが端末への配信を担当するので、ここでＳＩＰプロキシサーバがアドレス指定されなければならない。Ｓ−ＣＳＣＦは、ＳＩＰプロキシサーバのユーザプロファイル内の特別の情報によって指示されたように、その通常の動作を変更する。それ故、それをＰ−ＣＳＣＦに向けるＲｏｕｔｅフィールドの背後に、追加のＲｏｕｔｅフィールドとしてＳＩＰプロキシサーバの連絡アドレスを加える。Ｓ−ＣＳＣＦは、被要求ＵＲＩを含むＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤをやはり加えてもよいが、これは必要ではない。Ｐ−ＣＳＣＦに転送されるメッセージ２１３は、今は以下のように見える。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
ＩＮＶＩＴＥＳＩＰ：ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ
Ｆｒｏｍ：Ａｌｉｃｅ＜ａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ＞
Ｔｏ：Ｂｏｂ＜ｂｏｂ＠ｉｎｔｅｒｐｒｉｓｅ２．ｃｏｍ＞
Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ：ａｌｉｃｅ＠ｅｎｔｅｒｐｒｉｓｅ１．ｃｏｍ
Ｒｏｕｔｅ：ｐｃｓｃｆ２．ｏｐｅｒａｔｏｒ．ｃｏｍ
Ｒｏｕｔｅ：ｐｂｘ２−ｃｏｎｔａｃｔ−ａｄｄｒｅｓｓ
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Ｐ−ＣＳＣＦは、メッセージを受信すると、自装置のＲｏｕｔｅフィールドを取り去ってから、次に続くＲｏｕｔｅヘッダによって指示されるように、企業２のＳＩＰプロキシサーバにメッセージ２１４を転送する。企業２のＳＩＰプロキシサーバは、企業２の企業ネットワークを通してＢｏｂの端末への接続設定を担当する。宛先端末がＳＩＰ端末の場合、企業２のＳＩＰプロキシサーバは、メッセージを端末に直接配信できる。宛先端末がＳＩＰ端末でない場合、企業２のＳＩＰプロキシサーバは何らかのアプリケーション固有ロジックに従って着信処理をすることになる。

前述の事例では、ＵＲＩの中のワイルドカードシンボルを認識しそれらを配備する、またはメッセージの標準フォーマットを特定のフォーマットに適合させるようなＩＭＳノードの代替動作の幾つかのやり方を説明している。通常、これはＩＭＳノード機能の中に完全にハードコード化できよう。しかし、本発明の主題は、このような代替動作を必要な時にだけ行うことである。それ故、ＨＳＳに含まれるサブスクリプションは、このような代替動作を許可する第１のインジケータを備えてもよい。

この第１のインジケータにより、各ノードがサブスクリプションまたはユーザプロファイルの全部をスキャンする必要がなくなり、まずこのインジケータを調べることができるので、ＩＭＳの能力向上に役立つ。以下に述べるように、Ｓ−ＣＳＣＦがＩＭＳ内の他のノードに送信するユーザプロファイルの中に指示を含めるための、トークンでもある。

サブスクリプション内の第２の情報要素は、指示セットまたはルールセットとさらに呼ばれ、どの代替動作が期待されているかを定める。この第２の情報要素は、特定のユーザプロファイルまたは特定のサービスプロファイルまたは１つの専用のＰＵＩに対する、すべての場合に適用可能でもよい。この意味することは、１つを超える指示セットが存在してもよく、階層的なやり方さえ可能であるということである。

ノードは、ユーザプロファイルを受信すると、第２のタイプの情報の存在を調べるか、あるいはインジケータが存在するかどうかをまず調べる。ノードは、自装置に向けられた指示だけを読み出す。関連機能指示は登録された各ＰＵＩと一緒に格納され、機能指示はそのＰＵＩに関連してだけ実行されるように、ノードに知られている。ＰＵＩは、ＰＵＩに合致するすべてに対して指示が有効であるように、ワイルドカード化されてもよいし、また下位範囲でもよい。

もっと洞察を与えるために、ワイルドカード・シンボル・ルールおよびメッセージフォーマット化ルールの２つの例について、幾分より詳細に検討する。ワイルドカードの認識は、特定の文字を基にしている。この意味することは、ハードコード化されるとき、これらのシーケンスは、それらが意図されていなかったところでは起こらないであろうということである。第１のインジケータを用いて、このパラメータを設定している特定のサブスクリプションだけに限定される。それに属する指示は、シンボルおよびそれらが表す場所を指定する。例として、「！＊！」は４桁を意味し、また「！＃！」は１〜２０の英数文字を意味する。最初の例では、ＰＡＢＸが最後の４桁を使用するとき、最後の３桁だけを使用するＰＡＢＸと異なる事例であることは明白かもしれない。指示の別の例は、被要求ＵＲＩフィールドに最終宛先アドレスを含むことをＩＰ−ＰＢＸが必要とする（元の被要求ＵＲＩを維持する）場合の、Ｓ−ＣＳＣＦに対するようなフォーマット化ルールである。
−Ｐ−ＣＳＣＦからのメッセージの受信を必要とするＩＰ−ＰＢＸのＳＩＰ−ＵＲＩを、Ｐ−ＣＳＣＦのＲｏｕｔｅヘッダ下のＲｏｕｔｅヘッダに置く。
最終宛先の被要求ＵＲＩがＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールドの中にあることをＩＰ−ＰＢＸが必要とする場合の、Ｓ−ＣＳＣＦに対するこのようなフォーマット化ルールの例は、以下のとおりである。
−被要求ＵＲＩの値をＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールドにコピーする。
−メッセージを配信するために、被要求ＵＲＩフィールドをＩＰ−ＰＢＸのアドレスで置き換える
フォーマット化ルールに関しては、あるフィールドのコンテンツが、別のフィールドにコピーまたは移動される。コンテンツは生成されない。指示セットに対するあり得るシンタックスについて、以降の例に示す。

Ｉｎｓｔｒｕｃｔｉｏｎ＿ｓｅｔ：：｜＜ｉｎｓｔｒｕｃｔｉｏｎ＿ｔｙｐｅ＞＜ｉｎｓｔｒｕｃｔｉｏｎ＞，｜
Ｉｎｓｔｒｕｃｔｉｏｎ＿ｔｙｐｅ：：＝ｗｉｌｄｃａｒｄ，ｆｏｒｍａｔ＿ｒｕｌｅ，．．．．．．．．
Ｉｎｓｔｒｕｃｔｉｏｎ：：＜ｗｉｌｄｃａｒｄ＿ｉｎｓｔｒｕｃｔｉｏｎ＞，＜ｆｏｒｍａｔ＿ｒｕｌｅ＿ｉｎｓｔｒｕｃｔｉｏｎ＞，＜ｒｅｇｉｓｔｒａｔｉｏｎ＿ｕｐｄａｔｅ＿ａｌｌｏｗｅｄ＞，．．．．．．．．
Ｗｉｌｄｃａｒｄ＿ｉｎｓｔｒｕｃｔｉｏｎ：：＝＜ｗｉｌｄｃａｒｄ＿ｐａｔｔｅｒｎ＞＜ｓｕｂｓｔｉｔｕｔｅ＞
Ｆｏｒｍａｔ＿ｒｕｌｅ＿ｉｎｓｔｒｕｃｔｉｏｎ：：＜ｓｅｎｄｉｎｇ＿ｎｏｄｅ＞＜ｒｅｃｅｉｖｉｎｇ＿ｎｏｄｅ＞＜ｍｅｓｓａｇｅ＿ｔｙｐｅ＞＜ｓｏｕｒｃｅ＿ｆｉｅｌｄ｜ｓｏｕｒｃｅ＞＜ｄｅｓｔｉｎａｔｉｏｎ＿ｆｉｅｌｄ＞
Ｒｅｇｉｓｔｒａｔｉｏｎ＿ｕｐｄａｔｅ＿ａｌｌｏｗｅｄ：：＝Ｂｏｏｌｅａｎ

例えば、指示セットは以下のように見えるであろう。
Ｗｉｌｄｃａｒｄ；！＊！，４Ｄ
Ｗｉｌｄｃａｒｄ；！＃！，１−２０Ａ
Ｆｏｒｍａｔ＿ｒｕｌｅ；Ｓ−ＣＳＣＦ，Ｐ−ＣＳＣＦ，ＩＮＶＩＴＥ，ｒｅｇｉｓｔｅｒｅｄ＿ａｄｄｒｅｓｓ，ｒｏｕｔｅ
および
Ｗｉｌｄｃａｒｄ；！＊！，４Ｄ
Ｗｉｌｄｃａｒｄ；！＃！，１−２０Ａ
Ｆｏｒｍａｔ＿ｒｕｌｅ；Ｓ−ＣＳＣＦ，Ｐ−ＣＳＣＦ，ＩＮＶＩＴＥ，ｒｅｑｕｅｓｔｅｄ−ＵＲＩ，Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤ，
Ｆｏｒｍａｔ＿ｒｕｌｅ；Ｓ−ＣＳＣＦ，Ｐ−ＣＳＣＦ，ＩＮＶＩＴＥ，ｒｅｇｉｓｔｅｒｅｄ＿ａｄｄｒｅｓｓ，ｒｅｑｕｅｓｔｅｄ−ＵＲＩ

Claims

所定のやり方でＩＰマルチメディアサブシステムの機能を実行するノードと、
ＩＰマルチメディアサブシステムのユーザにサービスを行うＩＰマルチメディアサブシステムアプリケーションを有するアプリケーションサーバと、
前記ユーザにどのサービスがいつどのように実行されるべきかを指示する初期フィルタ基準を含む前記ユーザに関するサブスクリプションと
を備え、
前記サブスクリプションが、前記ユーザに対してそれらの機能を実行する前記ノードの標準的なやり方を変更させる、前記ＩＰマルチメディアサブシステムの前記ノードに対する機能指示を含むことを特徴とするＩＰマルチメディアサブシステム。
前記サブスクリプションは、前記ノードに前記機能指示の実行を許可する制御インジケータをさらに含むことを特徴とする、請求項１に記載のＩＰマルチメディアサブシステム。
少なくとも１つの前記機能指示はワイルドカード解釈指示であり、当該機能指示は、少なくとも１つのワイルドカード表示シンボルおよびそのシンボルに対する許容置換を定めることを特徴とする、請求項１に記載のＩＰマルチメディアサブシステム。
少なくとも１つの前記機能指示はフォーマット化ルール指示であり、当該機能指示は、前記ＩＰマルチメディアサブシステム内のソースノードから宛先ノードへのメッセージのフィールドに関して、当該フィールドの代替コンテンツの位置を定めることを特徴とする、請求項１に記載のＩＰマルチメディアサブシステム。
少なくとも１つの前記機能指示は更新指示であり、ノードがローカルに格納しているプロファイルを更新するために、当該機能指示が前記登録メッセージ内の更新ユーザプロファイルを使用するように該ノードに指示することを特徴とする、請求項１に記載のＩＰマルチメディアサブシステム。
ホーム加入者サーバは、さらに、前記制御インジケータと前記機能指示とを含む前記ＩＰマルチメディアサブシステムのユーザのサブスクリプションを保持し、当該サブスクリプションを前記ＩＰマルチメディアサブシステムのノードに配信することを特徴とする、請求項２に記載のＩＰマルチメディアサブシステム。
−ユーザが前記ＩＰマルチメディアサブシステムに登録するとき、前記制御インジケータがホーム加入者サーバから受信した該ユーザのサブスクリプション内に存在するかどうかをチェックする工程と、
−存在する場合、前記サブスクリプションに含まれた前記機能指示を実行する工程と
を有することを特徴とする、請求項２に記載のＩＰマルチメディアサブシステムのノードの動作方法。
−位置情報要求で受信したパブリック・ユーザ・アイデンティティに合致するパブリック・ユーザ・アイデンティティを探してサブスクリプションをスキャンする工程と、
−前記パブリック・ユーザ・アイデンティティに合致するサブスクリプション内に前記制御インジケータがあるかどうかをチェックする工程と、
−前記制御インジケータがある場合、そのサブスクリプションに含まれた前記機能指示を実行する工程と
を有することを特徴とする、請求項２に記載のＩＰマルチメディアサブシステムのホーム加入者サーバの動作方法。
プロキシ呼セッション制御機能と、サービング呼セッション制御機能と、ホーム加入者サーバとをそれぞれ少なくとも１つ備えるＩＰマルチメディアサブシステムネットワークのサービスへの、当該ネットワークのアクセスポイントに収容されたユーザ端末によるアクセスを促進する方法であって、
前記アクセスポイントは前記ＩＰマルチメディアサブシステムネットワークのサブスクリプションに関連づけられており、
−前記アクセスポイントの前記ＩＰマルチメディアサブシステムネットワークへのＩＰマルチメディアサブシステム登録の際に、暗黙的な登録セット内の前記パブリック・ユーザ・アイデンティティおよび前記機能指示を、前記アクセスポイントに割り当てられたサービング呼セッション制御機能および前記アクセスポイントが接続しているプロキシ呼セッション制御機能に対して配信する工程と、
−前記アクセスポイントに収容されたユーザ端末向けのＩＮＶＩＴＥメッセージの処理の際に、前記サービング呼セッション制御機能が、Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−Ｉｄｅｎｔｉｔｙヘッダ内に元の被要求ＵＲＩを保存し、前記元の被要求ＵＲＩを前記アクセスポイントの前記パブリック・ユーザ・アイデンティティで置換する工程と、
−前記変更されたＩＮＶＩＴＥメッセージを前記プロキシ呼セッション制御機能に転送する工程と
を有することを特徴とする方法。
前記暗黙的な登録セットは、前記アクセスポイントの明示的なパブリック・ユーザ・アイデンティティを少なくとも１つ含むことを特徴とする、請求項９に記載の方法。
前記暗黙的な登録セットが、登録の際に前記ホーム加入者サーバから前記サービング呼セッション制御機能および前記プロキシ呼セッション制御機能へ、サーバ割り当て回答内の２００ＯＫメッセージのＰ−Ａｓｓｏｃｉａｔｅｄ−ＵＲＩヘッダの中で送信されることを特徴とする、請求項９に記載の方法。
前記暗黙的な登録セットが、前記サブスクリプションが変更された後にプッシュプロファイル要求内で、前記ホーム加入者サーバから前記サービング呼セッション制御機能に提供されることを特徴とする、請求項９に記載の方法。
前記暗黙的な登録セットは、少なくとも１つのワイルドカード解釈指示と、パブリック・ユーザ・アイデンティティの範囲を表す少なくとも１つのワイルドカード・パブリック・ユーザ・アイデンティティもしくはパブリック・ユーザ・アイデンティティ・サブドメインとを含むことを特徴とする、請求項９に記載の方法。
前記暗黙的な登録セットは、少なくとも１つのフォーマット化ルール指示を含むことを特徴とする、請求項９に記載の方法。
前記暗黙的な登録セットは、少なくとも１つの更新指示を含むことを特徴とする、請求項９に記載の方法。
前記アクセスポイントは、ＩＰ構内交換機であることを特徴とする、請求項９に記載の方法。
前記アクセスポイントは、ＳＩＰプロキシサーバであることを特徴とする、請求項９に記載の方法。
前記暗黙的な登録セットは、前記サブスクリプションが未登録であるとき、セッション設定要求の受信の際に提供されることを特徴とする、請求項９に記載の方法。
ＩＰマルチメディアサブシステムネットワークのノードであって、
ユーザプロファイルが機能指示を含むかどうかを検出する指示検出手段と、
前記ノードに対して有効な前記ユーザプロファイルからの指示を選択し、それらを登録されたＰＵＩとともに格納する指示選択格納手段と、
登録されたＰＵＩと一緒に格納された機能指示を実行する指示実行手段と
を備え、請求項７又は９に記載の方法を実行するように構成されることを特徴とするノード。
請求項１９に記載のＩＰマルチメディアサブシステムネットワークのノードとして動作可能で、適合されたプログラムを有することを特徴とする汎用コンピュータ。