JP5247709B2 - 中間ノードが利用不可能な場合にｓｉｐメッセージを経路指定する方法 - Google Patents

Description

本発明は、信号伝達経路のノードを構成する中間エンティティを経由して経路指定されるべきＳＩＰメッセージを経路指定する方法に関連する。

本発明は、メッセージが伝送中に通過しなければならない１つ以上の中間エンティティが、利用不可能であると共に、従って同じ信号伝達経路上の他のエンティティによってコンタクトされない可能性がある状況において、特に有利なアプリケーションを見い出す。

電気通信ネットワークは、送信元エンティティと送信先エンティティとの間で伝送された信号伝達メッセージが伝送中に通過する様々な中間エンティティによって構成される。信号伝達メッセージは、例えば、メッセージ通信システム（messaging system）におけるメッセージの存在の通知のような、他の情報と共に、“コール設定”リクエスト（call set-up request）のような、送信元エンティティから送信先エンティティに対するコールに連結された情報を含む。

これらの中間エンティティは、信号伝達メッセージを経路指定することから、特定のサービスを提供する目的で、ある種の情報を挿入するか、もしくは削除することのように、そのメッセージによって達成されるべき動作まで、非常に多様な役割を有することができる。

セッション確立プロトコル（ＳＩＰ：Session Initiation Protocol）は、最初は、ＩＰネットワークにおけるマルチメディアセッションの設定、変更、及び終了を可能にする目的で、インターネット技術タスクフォース（ＩＥＴＦ：Internet Engineering Task Force）によって定義される。ＳＩＰは、同様に、ＩＰ伝送に基づくネットワーク制御アーキテクチャのそれらの定義の枠組において、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）及びＴＩＳＰＡＮ（Telecoms & Internet converged Services & protocols for Advanced Networks）のような、様々な標準化団体及びコンソーシアムによって採用された。それらのアーキテクチャは、ＩＰマルチメディアサブシステム（ＩＭＳ）アーキテクチャを含む。移動通信か、または固定通信かに拘らず、ＳＩＰの使命は、従って、動作中の公衆通信網に使用されるセッション設定プロトコルとして、自身を確立することである。

他の信号伝達プロトコルと比較すると、ＳＩＰは、ＳＩＰメッセージそれ自身で経路指定情報を伝達する能力によって特徴付けられる。これは、セッションを開始すると共に、最初のリクエストと呼ばれる第１番目のリクエストが、それが通過しなければならないエンティティのアドレスを含むことができるからである。このデータは、ネットワークにおける登録の時か、もしくは他のメカニズムによって、送信元エンティティによって復元されて、セッションの根源である送信元エンティティによって最初のリクエストメッセージに入力される。最初のリクエストが送信されるときに、コールの宛先、ネットワークのアーキテクチャ、及びセッションに必要なサービスに応じて、セッションに対応する信号伝達経路が設定される。次のＳＩＰリクエスト及びＳＩＰレスポンスは、それらを経路指定するために必要なデータを全て含む。これは、他のプロトコルと比較した主要な差異点であって、それに関して経路指定は、本質的に、ネットワークのエンティティ内に含まれるテーブル、及びコールに連結された経路指定データを格納するコールに関与するエンティティに基づいている。

リクエスト及びそれに対するレスポンスという２つのタイプのＳＩＰメッセージがある。レスポンスは、関連するリクエストに対して、逆の経路をたどる。

最初のリクエストと次のリクエストとの間では区別が行われる。次のリクエストは、送信元エンティティにより送信された最初のリクエストによって生成された同じＳＩＰダイアログの一部である。いくらかの最初のリクエストのみが、ＳＩＰダイアログ、例えば“ＩＮＶＩＴＥ”メッセージを生成し得る。次のリクエストの経路、すなわちこのダイアログの一部である全てのリクエストが通過しなければならないネットワークのＳＩＰエンティティのセットは、ダイアログを生成する最初のリクエストを送信する時に決定される。

ＳＩＰの最初のリクエストメッセージは、リクエストの送信先エンティティのアドレスを含む“Ｒｅｑｕｅｓｔ−ＵＲＩ”ヘッダを有する（ここで、ＵＲＩは、“Uniform Resource Identifier”を表す。）。ＳＩＰリクエストは、そのリクエストが通過しなければならない中間エンティティである、目的地に達する前に通過されるべきエンティティの身元のリストを、先のものから順に、そしてＵＲＩの形で含む特定の“Ｒｏｕｔｅ”ヘッダを任意に有することができる。

中間のＳＩＰエンティティ、一般的にはＳＩＰプロキシは、最初のリクエストを受信すると、それを分析することを開始する。もしリクエストが“Ｒｏｕｔｅ”ヘッダを含むならば、エンティティは、その場合に、このヘッダに含まれる第１番目のＳＩＰエンティティを、自身がそれに対してリクエストを送信しなければならないエンティティであると見なす。もしそうでなければ、エンティティは、特定の経路指定メカニズムを使用して、“Ｒｅｑｕｅｓｔ−ＵＲＩ”ヘッダから、それに対してリクエストが送信されなければならない次のエンティティを決定する。

それが中間エンティティであるか否かに拘らず、あらゆるＳＩＰエンティティは、“Ｒｏｕｔｅ”ヘッダまたは追加のエンティティのＵＲＩを、現存する“Ｒｏｕｔｅ”ヘッダに加え得る。この機能は、多くの用途を有している。例えば、それは、リクエストがそのエンティティを通過することを保証するために、コンタクトされたネットワークの第１番目のエンティティが、“Ｒｏｕｔｅ”ヘッダに、リクエストを送信するエンティティのユーザに対して割り当てられたサービスの管理に関与するエンティティの識別子を加えることを可能にする。サービスの管理に関与するエンティティは、アプリケーションサーバ（ＡＳ：application server）として知られている。

信号伝達経路内に留まることを望む、最初のリクエストが通過する中間のＳＩＰエンティティは、最初のリクエストを次のノードに送信する前に、それらの識別子を、最初のリクエストの“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに挿入する。

最初のリクエストを送信する時に“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに含まれる識別子は、次のリクエストの“Ｒｏｕｔｅ”ヘッダにおいて反復される。これらのリクエストは、以下の方法において経路指定される。中間のＳＩＰエンティティは、次のＳＩＰリクエストを受信すると、それを分析することを開始する。もしリクエストが“Ｒｏｕｔｅ”ヘッダを含むならば、その場合に、このエンティティは、このヘッダに含まれる第１番目のＳＩＰエンティティを、自身がそれに対してリクエストを送信しなければならないエンティティであると見なす。もしそうでなければ、このエンティティは、“Ｒｅｑｕｅｓｔ−ＵＲＩ”ヘッダに含まれるエンティティを、自身がそれに対してリクエストを送信しなければならないエンティティであると見なす。

ＳＩＰリクエストを送信をする時に、通過される各エンティティは、そのアドレスを“Ｖｉａ”ヘッダに加える。従って、リクエストを送信するエンティティのアドレスを含んで、このヘッダは、通過されるＳＩＰエンティティの全てのアドレスを順番に蓄積する。

リクエストの送信先エンティティまたは中間エンティティであるエンティティが、リクエストに対するレスポンスを生成する場合に、エンティティは、リクエストの“Ｖｉａ”フィールドにおいて受信されたアドレスを含む“Ｖｉａ”ヘッダを、同じ順番でそれらの中に挿入する。このリクエストを受信する各エンティティは、もしそれが次のノードにそのリクエストを送信することを決定するならば、このレスポンスの“Ｖｉａ”ヘッダにおける第１番目であるアドレスに対してそれを送信する。

一般的に言えば、中間エンティティは、その時々に、例えば機器故障または過負荷の場合に、アクセス可能ではないことがあり得る。そのような状況において、ネットワークは、あらゆるそのようなエンティティを伝送中に通過するべきであるメッセージが拒絶される方法か、またはメッセージがいずれにせよその送信先へ伝達されることを可能にするバイパス経路が発見される方法、の２つの方法で動作し得る。この動作は、特に、すなわちそれが必須か否かに拘らず、関係のあるエンティティの特性によって決まると共に、信号伝達メッセージタイプによって決まる。

ＳＩＰは、一般的に、この選択肢を提供せず、そして、第１番目の解決法、すなわち、メッセージの拒絶だけを可能にする。

従って、中間エンティティが、リクエストの“Ｒｏｕｔｅ”ヘッダにおける第１番目のＳＩＰエンティティがアクセス可能ではないと判定するとき、その場合に、たとえ、このアクセス不可能な中間エンティティを回避して、リクエストを、その送信先まで伝達することが望ましかったであろうとしても、そして、たとえ、それが作用したであろう処理動作から利益を得ることができないとしても、中間エンティティは、送信元エンティティに“故障”レスポンスを送信することができる。

同様に、もし中間エンティティが、次のノードにＳＩＰレスポンスを送信すると共に、そのアドレスがそのレスポンスの“Ｖｉａ”ヘッダにおける第１番目のアドレスであるＳＩＰエンティティがアクセス可能ではないと判定するならば、たとえ、アクセス不可能な中間エンティティを回避して、このレスポンスを、その送信先へ伝達することが望ましかったであろうとしても、その場合に、中間エンティティは、そのレスポンスを送信することを中止すると共に、そのレスポンスに対応する処理もキャンセルすることができる。

従って、たとえ、メッセージの信号伝達経路に位置する中間エンティティが利用可能ではないとしても、メッセージの拒絶が回避されることを可能にする技術に関する必要性が存在する。

本発明は、ＳＩＰメッセージが信号伝達経路のノードを構成する中間エンティティを経由して経路指定されるべき電気通信ネットワークにおける経路指定方法であって、前記方法が、利用不可能な場合にはバイパスされ得る中間エンティティをバイパスするステップを含み、前記バイパスするステップが、通過されるべきエンティティの識別子のリストを含むＳＩＰメッセージのヘッダ内のバイパスされるべき前記中間エンティティの識別子を消去することによって達成されることを特徴とする方法を提案することによって、この必要性に対処する。

本発明は、従って、ＳＩＰメッセージが、たとえそれが“Ｒｏｕｔｅ”または“Ｖｉａ”ヘッダに示された中間エンティティを伝送中に通過し得ないとしても、その目的地に達することを可能にするという利点を有する。もし、アクセス不可能なエンティティによって提供された機能が、システムの動作を訂正するために重要ではないならば、そして、リクエストまたはレスポンスが拒絶されるよりむしろそのエンティティを回避して、その目的地に到達することが望ましいならば、この機能は、非常に有益である。

本発明の経路指定方法は、中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するステップを有利に含む。

第１の実施例において、前記判定するステップは、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示すローカルデータを使用して実行される。

第２の実施例において、前記判定するステップは、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示す外部データベースを調べることによって実行される。

第３の実施例において、前記判定するステップは、バイパスされ得る前記中間エンティティの前記ＳＩＰメッセージの経路指定ヘッダにバイパスする指標を挿入することによって達成される。

本発明は、ＳＩＰから著しく分岐しないということが理解され得る。それは、本発明の方法を実行する中間エンティティによる特定の機能の実装だけを必要とし、そのエンティティは、通常の方法で動作する他のＳＩＰエンティティに包囲され得る。

リクエストメッセージに関連する本発明の一実施例において、前記ヘッダは、送信元エンティティによって送信されたＳＩＰリクエストメッセージの“Ｒｏｕｔｅ”ヘッダである。

この実施例の第１の変形において、前記中間エンティティの前記バイパスする指標は、最初のリクエストメッセージを送信する送信元エンティティに対して、電気通信ネットワークにおける前記送信元エンティティの登録の間に伝送される。使用されるヘッダは、その場合に、“登録（ＲＥＧＩＳＴＥＲ）”メッセージの“Ｐａｔｈ”ヘッダと、“登録（ＲＥＧＩＳＴＥＲ）”メッセージに対する“２００ ＯＫ”レスポンスメッセージの“Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅ”ヘッダである。

この実施例の第２の変形において、前記中間エンティティの前記バイパスする指標は、前記送信元エンティティに対して、最初のリクエストメッセージを送信する前に伝送される。

この実施例の第３の変形において、前記バイパスの指標は、最初のリクエストメッセージを送信する際に、前記中間エンティティによって、“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに挿入されると共に、前記“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダは、前記最初のリクエストメッセージを送信するエンティティによって、前記最初のリクエストに対するレスポンスメッセージにおいて受信されると共に、前記送信元エンティティによって、次のリクエストメッセージの“Ｒｏｕｔｅ”ヘッダに複写される。

この実施例の第４の変形において、前記バイパスの指標は、最初のリクエストメッセージを送信する際に、前記中間エンティティ以外の中間エンティティによって、“Ｒｏｕｔｅ”ヘッダに挿入される。

レスポンスメッセージに関連する別の実施例において、前記ヘッダは、ＳＩＰリクエストメッセージの“Ｖｉａ”ヘッダである。

本発明によれば、この実施例において、前記バイパスの指標は、前記中間エンティティによって、リクエストメッセージの“Ｖｉａ”ヘッダに挿入される。“Ｖｉａ”ヘッダは、その場合に、レスポンスを送信するエンティティによって、レスポンスメッセージに複写される。

本発明は、同様に、電気通信ネットワークにおいてＳＩＰメッセージを経路指定するための、信号伝達経路のノードを構成する中間エンティティであって、前記中間エンティティが、前記ＳＩＰメッセージの経路指定ヘッダに、もし前記エンティティが利用不可能である場合のバイパスの指標を挿入し得ることを特徴とする中間エンティティに関連する。

本発明は、更に、電気通信ネットワークにおいてＳＩＰメッセージを経路指定するための、信号伝達経路のノードを構成するエンティティであって、前記エンティティが、中間エンティティが利用不可能な場合には、通過されるべきエンティティの識別子のリストを含むＳＩＰメッセージのヘッダ内のバイパスされるべき前記中間エンティティの識別子を消去することができる、前記中間エンティティをバイパスするための手段を備えることを特徴とするエンティティに関連する。

本発明によれば、前記エンティティは、中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するための手段を備える。

本発明は、更に、コンピュータプログラムであって、前記プログラムがコンピュータによって実行されるときに本発明の方法を実行するためのプログラム命令を含むことを特徴とするコンピュータプログラムに関連する。

本発明は、最終的に、利用不可能な場合にはバイパスされ得る信号伝達経路内の中間エンティティをバイパスする指標を経路指定ヘッダ内に含むＳＩＰメッセージを伝送することを特徴とする信号に関連する。

ＩＭＳアーキテクチャネットワークにおけるＳＩＰリクエストメッセージの経路指定方法を例証する図である。 図１のＩＭＳネットワークのノードを構成する種々のエンティティの間の信号伝達メッセージの経路指定に関する本発明の方法の図である。

限定しない例として提供される添付された図面を参照する以下の説明は、本発明が何から構成されるか、そしてそれは実行するためにどう減少され得るかについて説明する。

図１は、ＩＭＳネットワークにおいて、送信元エンティティＡによって送信先エンティティＢに対して送信されたＳＩＰリクエストメッセージの信号伝達経路を表す。これらのエンティティＡ及びＢは、固定通信もしくは移動通信の電話端末であって、例えば端末Ａは端末Ｂに対する電話コールを開始する。

現在、ＩＭＳアーキテクチャは、基本的に、電話、テレビ電話、プレゼンス（presence）、及びインスタントメッセージングタイプのアプリケーションに関して定義される。

図１のネットワークは、以下の、
・ＩＭＳネットワークにおける端末Ａ及びＢの第１番目の接触点であると共に、伝送ネットワークの資源との相互作用を管理するＰ−ＣＳＣＦ（Proxy-Call Server Control Function）プロキシサーバＰＡ及びＰＢと、
・ＩＭＳネットワークにおける端末Ａ、及び特に、それによって端末Ａのユーザが１つ以上のサービスに加入するアプリケーションサーバに対するトリガポイント（trigger point）を管理するＳ−ＣＳＣＦ（Serving-Call Server Control Function）サーバＳ（Ｓ−ＣＳＣＦサーバＳは、端末ＡがＩＭＳネットワークにおいて登録されるとき、端末Ａに割り当てられる。）と、
・問題のサービス、例えばコール転送サービスに関連付けられたアプリケーションサーバ（ＡＳ）（アプリケーションサーバＡＳは、加入されたサービスに関する全ての情報を含む。）と、
を有する２つの端末Ａ及びＢの間の様々な中間エンティティを備える。

もし中間エンティティが、“Ｒｏｕｔｅ”ヘッダを含む最初のＳＩＰリクエストメッセージまたは次のＳＩＰリクエストメッセージ、あるいは“Ｖｉａ”ヘッダを含むＳＩＰレスポンスメッセージを受信するならば、それは、そのメッセージを、“Ｒｏｕｔｅ”ヘッダまたは“Ｖｉａ”ヘッダにおいて示された信号伝達経路上の次のノードに送信しなければならない。しかしながら、もし次のノードが利用不可能であるので、そのノードがコンタクトされない可能性があるならば、中間エンティティは、それをバイパスすると共に、ＳＩＰメッセージを、関係のあるヘッダにおける更に次のノードに送信することを決定し得る。もしそのノードが同様にアクセス不可能であるならば、中間エンティティは、それをもバイパスすることを決定し得る。

以下の３つのメカニズム、
・エンティティがコンタクトされない可能性があることを判定するメカニズムと、
・もしエンティティがコンタクトされない可能性がある場合、そのエンティティがバイパスされ得るか否かを判定するメカニズムと、
・ＳＩＰリクエストが発生した場合に、“Ｒｏｕｔｅ”ヘッダに含まれるエンティティをバイパスするか、またはＳＩＰレスポンスが発生した場合に、“Ｖｉａ”ヘッダに含まれるエンティティをバイパスするメカニズムと、
は区別され得る。

ＳＩＰエンティティは、別のエンティティがコンタクトされない可能性があることを、以下の、
・２つのエンティティ間の物理的トランスポート層におけるアクティビティ検出（維持（keep alive））メカニズムによる方法（例えば、端末は、ネットワークにおけるそれらの存在を示すために“Ｈｅｌｌｏ”メッセージを定期的に送信すると共に、もし端末がそのようなメッセージをもはや送信していないならば、それは利用不可能であることが考えられる。）、及び、
・ＳＩＰリクエストまたはＳＩＰレスポンスを送信しようと試みる時に、物理的トランスポート層を介して“故障”メッセージを送信することによる方法、
の２つの方法で判定し得る。

別のエンティティが利用不可能であると判定したので、利用不可能なエンティティによるＳＩＰメッセージの送信が必須か否かに応じて、中間エンティティは、その別のエンティティがバイパスされ得るか否かを識別しなければならない。例えば、コール転送機能は、端末Ａと端末Ｂとの間に電話コールを設定して維持することに、必須ではない。同様に、もしこの機能に関与するアプリケーションサーバＡＳが利用不可能になるならば、ＳＩＰリクエストメッセージ及びＳＩＰレスポンスメッセージにとって、それをバイパスすることが可能でなければならない。

コンタクトされない可能性がある別のエンティティがバイパスされるべきであるか否かを第１番目のエンティティが判定するために、様々な方法がある。

第１の方法において、第１番目のエンティティは、ある状況下で、コンタクトされない可能性があるエンティティがバイパスされ得るか否かを第１番目のエンティティが見分けることを可能にするローカルデータを保持する。例えば、端末Ａは、もしプロキシサーバＰＡが利用不可能であるならば、端末ＡがプロキシサーバＰＡをバイパスする権限を与えるデータを有する。

第２の方法において、第１番目のエンティティは、同じ情報を獲得するために、外部のサーバまたはデータベースを調べる。

本発明は、更に、それによって、コンタクトされない可能性があるエンティティがバイパスされ得るか否かに関する情報が、関係のあるＳＩＰメッセージの“Ｒｏｕｔｅ”ヘッダまたは“Ｖｉａ”ヘッダにおけるそのエンティティの識別子と関連付けられる別の方法を提案する。この情報は、利用不可能なエンティティのＵＲＩにおける、以下ではバイパスインジケータ（bypass indicator：バイパスの指標／バイパスする指標）と呼ばれる新しいパラメータに含まれる。バイパスパラメータは、以下の値、例えばイエスかノーの値を有することができる。このパラメータの欠如が示すのは、ＵＲＩのこの拡張が適用できないということである。

ＳＩＰレスポンスに関して、このパラメータは、コンタクトされない可能性があるエンティティによって、そのＵＲＩを対応するリクエストの“Ｖｉａ”ヘッダに挿入する場合に加えられ得る。

リクエストに関して、バイパスインジケータは、コンタクトされない可能性があるエンティティのＵＲＩに、様々な方法で挿入され得る。・例えば、ネットワークにおいて送信元エンティティを登録する段階の間、バイパスパラメータで補強された中間エンティティのＵＲＩが、“登録”メッセージの“Ｐａｔｈ”ヘッダか、または“登録”メッセージに対する“２００ ＯＫ”レスポンスメッセージにおける“Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅ”ヘッダに挿入される。

“Ｐａｔｈ”ヘッダは、端末に対する経路をＵＲＩのリストの形式で登録するために、端末の登録の段階の間に使用される。この情報は、その場合に、端末にアドレス指定された最初のリクエストの“Ｒｏｕｔｅ”ヘッダ内にその端末に到達するための信号伝達経路を示すために、この端末を登録したＳ−ＣＳＣＦプロキシサーバによって使用される。

“Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅ”ヘッダは、ユーザのサービスを管理するＳ−ＣＳＣＦプロキシサーバＳに到達するための経路を登録するために使用される。その経路は、その場合に、登録された端末によって送信される最初のリクエストがＳ−ＣＳＣＦプロキシサーバに経路指定されるように、登録された端末によって送信される最初のリクエストの“Ｒｏｕｔｅ”ヘッダに挿入される。“Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅ”ヘッダは、“登録（ＲＥＧＩＳＴＥＲ）”リクエストに応答して、端末を登録したプロキシによって送信された登録を承認する“２００ ＯＫ”メッセージに挿入される。

・もし前記ＵＲＩが予め設定されるならば、バイパスインジケータは、“Ｒｏｕｔｅ”ヘッダを構成するＵＲＩに含まれ得る。これらのＵＲＩは、最初のリクエストを送信するＳＩＰエンティティによって加えられる。例えば、端末Ａは、最初のリクエストメッセージが送信される前に端末Ａに伝達された、予め設定されたエンティティのＵＲＩを、“Ｒｏｕｔｅ”ヘッダに挿入するように構成され得る。

・バイパスインジケータを加えた中間エンティティのＵＲＩは、最初のリクエストメッセージを送信する際に、前記中間エンティティによって、“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに挿入される。この“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダは、その場合に、最初のリクエストメッセージを送信するエンティティによって、最初のリクエストに対するレスポンスメッセージにおいて受信されると共に、送信元エンティティによって、次のリクエストメッセージの“Ｒｏｕｔｅ”ヘッダに複写される。

・バイパスインジケータは、最初のリクエストメッセージを送信する際に、関係のある中間エンティティ以外の中間エンティティによって、“Ｒｏｕｔｅ”ヘッダに挿入される。

バイパスパラメータが、メッセージが受信される状況及びメッセージタイプを考慮するための他の値によって補強され得ることに留意すべきである。

例えば、
・ｍｅｓｓａｇｅＴｙｐｅ：そのメッセージがこのパラメータによって指定されたタイプのメッセージである場合にかぎり、エンティティはバイパスされ得る。
・ｅａｒｌｙＤｉａｌｏｇ：関係のあるメッセージがＳＩＰアーリーダイアログ（SIP early dialogue）において受信される場合にかぎり、エンティティはバイパスされ得る。
・ｃｏｎｆｉｒｍｅｄＤｉａｌｏｇ：関係のあるメッセージがＳＩＰコンファームドダイアログ（SIP confirmed dialogue）において受信される場合にかぎり、エンティティはバイパスされ得る。

ＳＩＰコンファームドダイアログ、及びＳＩＰアーリーダイアログは、文書ＲＦＣ ３２６１において定義される。

ＳＩＰリクエストメッセージを送信する際に、そのＵＲＩが“Ｒｏｕｔｅ”ヘッダにおける第１番目のＵＲＩである中間エンティティをバイパスすることを、もしエンティティが決定するならば、そのエンティティは、その中間エンティティのＵＲＩを“Ｒｏｕｔｅ”ヘッダから削除しなければならない。エンティティは、その場合に、このように修正されたリクエストに標準のＳＩＰ経路指定手順を適用する。もし“Ｒｏｕｔｅ”ヘッダによって定義された信号伝達経路における次のノードが同様にアクセス不可能であるならば、この動作は繰り返され得る。従って、多くのノードが同時にバイパスされ得る。

同様に、ＳＩＰレスポンスメッセージを送信する際に、そのＵＲＩが“Ｖｉａ”ヘッダにおける第１番目のＵＲＩである中間エンティティをバイパスすることを、もしエンティティが決定するならば、そのエンティティは、その中間エンティティのＵＲＩを“Ｖｉａ”ヘッダから削除しなければならない。エンティティは、その場合に、このように修正されたレスポンスに標準のＳＩＰ経路指定手順を適用する。もし“Ｖｉａ”ヘッダによって定義された信号伝達経路における次のノードが同様にアクセス不可能であるならば、この動作は繰り返され得る。従って、多くのノードが同時にバイパスされ得る。

ＩＭＳアーキテクチャにおけるコール転送サービスを実行する本発明の例は、図２を参照して、以下で説明される。コール転送は、コールにおいて、このサービスに加入するユーザ（送信元エンティティ）によって、いつでも起動され得る。

３ＧＰＰによって現在定義されたアプリケーションサーバＡＳに関する起動メカニズムは、セッションまたはコールを開始する第１番目のリクエストによってのみ、ＡＳの起動を可能にする。従って、コール転送アプリケーションサーバＡＳがいつでもコールに介入することができなければならないと仮定すると、コール転送アプリケーションサーバＡＳは、コールの開始と同時に、起動されると共に、転送サービスに対する加入者に影響を与えるあらゆるコールに関するＳＩＰ信号伝達経路に挿入されなければならない。コール転送アプリケーションサーバＡＳがもはや利用可能ではないならば、このサーバを通過するコールが正常に伝送され続けることを可能にするために、サーバは、そのＵＲＩを最初のリクエストの“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに挿入する前に、パラメータ“バイパス＝ＹＥＳ”を、そのＵＲＩに加える。従って、もしこのアプリケーションサーバＡＳが、コールのセットアップの間に、またはコールがセットアップされたときに、機能しなくなる場合、Ｓ−ＣＳＣＦは、それをバイパスすることになる。

１．Ａは、Ｂに対するコールを開始するために、“ＩＮＶＩＴＥ”リクエストメッセージを、“ＰＡ”と表示されると共にＡが接続される、ＡのＰ−ＣＳＣＦプロキシサーバに送信する。このメッセージは、“Ｒｏｕｔｅ”ヘッダの中に、Ａのサービスの実行に関与するＳ−ＣＳＣＦサーバＳのＵＲＩ、及びプロキシＰＡのＵＲＩを含む。エンティティＰＡは、端末ＡとＳ−ＣＳＣＦサーバＳとの間の信号伝達経路の一部分である中間エンティティである。

２．Ｐ−ＣＳＣＦプロキシサーバＰＡは、Ｐ−ＣＳＣＦプロキシサーバＰＡが次のリクエストを受信できるように、Ｐ−ＣＳＣＦプロキシサーバＰＡのＵＲＩを含む“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダを加えた後、“Ｒｏｕｔｅ”ヘッダからＰ−ＣＳＣＦプロキシサーバＰＡのＵＲＩを削除し、その後、リクエストを、そのＵＲＩが今このヘッダの第１番目のＵＲＩであるＳ−ＣＳＣＦサーバＳに送信する。

３．Ｓ−ＣＳＣＦサーバＳは、Ａが、コール転送サービスに加入すると共に、このサービスを提供することに関与するエンティティＡＳを起動することを決定する、と判定する。Ｓ−ＣＳＣＦサーバＳは、転送ＡＳを通過した後でリクエストがＳ−ＣＳＣＦサーバＳに戻るようにするために、“ＩＮＶＩＴＥ”リクエストを転送ＡＳに送信する前に、Ｓ−ＣＳＣＦサーバＳ自身のＵＲＩを従えている転送ＡＳのＵＲＩを、“ＩＮＶＩＴＥ”リクエストの“Ｒｏｕｔｅ”ヘッダに加える。

４．転送ＡＳは、そのコールの信号伝達経路の中に留まると共に、Ａが起動する転送サービスを提供することができるように、転送ＡＳのＵＲＩを“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに加えて、“ＩＮＶＩＴＥ”リクエストを、そのＵＲＩが“Ｒｏｕｔｅ”ヘッダにおける次のＵＲＩであるＳ−ＣＳＣＦサーバＳに返信する。“転送”ＡＳのＵＲＩは、もし転送ＡＳがコンタクト不可能状態になるならば、このＡＳがバイパスされ得ることを示すために、パラメータ“バイパス＝ＹＥＳ”を含む。

５．Ｓ−ＣＳＣＦサーバＳは、“ＩＮＶＩＴＥ”リクエストメッセージを、“ＰＢ”と表示されると共にＢが接続される、ＢのＰ−ＣＳＣＦプロキシサーバに送信する前に、Ｓ−ＣＳＣＦサーバＳのＵＲＩを“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに加える。

６．Ｐ−ＣＳＣＦプロキシサーバＰＢは、“ＩＮＶＩＴＥ”リクエストをＢに送信する前に、Ｐ−ＣＳＣＦプロキシサーバＰＢのＵＲＩを“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダに加える。

７、８、９、１０、１１、及び１２．ＢはＡからのコールを受け入れると共に、“２００ ＯＫ”レスポンスメッセージを送信する。このレスポンスは、“ＩＮＶＩＴＥ”リクエストを送信する際に“Ｖｉａ”ヘッダにスタックされた、“ＩＮＶＩＴＥ”リクエストによってたどられた経路の逆の経路に沿って、Ａに経路指定される。このレスポンスは、コールの中間エンティティをＡに示すために、“ＩＮＶＩＴＥ”メッセージにおいてＢが受信した“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダを含む。

１３、１４、１５、１６、１７、１８．Ａは、“２００ ＯＫ”レスポンスの受信を確認すると共に、リクエストＡＣＫを送信する。このリクエストは、最初の“ＩＮＶＩＴＥ”リクエストを送信する際に“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダにスタックされた経路をたどる。Ａは、“ＩＮＶＩＴＥ”リクエストに対するＳＩＰの“２００ ＯＫ”レスポンスの“Ｒｅｃｏｒｄ−Ｒｏｕｔｅ”ヘッダにおいて受信されたＵＲＩを含む“Ｒｏｕｔｅ”ヘッダを、リクエストＡＣＫに挿入する。“２００ ＯＫ”レスポンスは、他の緊急のレスポンス、特にＢが警報を出されたことを示すリンギング（ringing）レスポンス１８０によって先行され得る。簡単化のために、これらのレスポンスと、リクエストＡＣＫの“Ｒｏｕｔｅ”ヘッダと、“２００ ＯＫ”レスポンスの“Ｖｉａ”ヘッダは、この図には表されていない。

１９．Ｂは、Ａに“逆ＩＮＶＩＴＥ（re-INVITE）”リクエストメッセージを送信する。例えば、このリクエストは、例えばコーデックの変更のような、メディアセッションのパラメータを取り決めるために、またはセットアップされたセッションを更新（refresh）するために、送信され得る。

２０．Ｐ−ＣＳＣＦプロキシサーバＰＢは、Ｓ−ＣＳＣＦサーバＳに対して、“Ｒｏｕｔｅ”ヘッダに基づいて“逆ＩＮＶＩＴＥ（re-INVITE）リクエスト”を経路指定する。

２１．Ｓ−ＣＳＣＦサーバＳは、転送ＡＳがもはやコンタクトされることができないと判定すると共に、“Ｒｏｕｔｅ”ヘッダにおいて受信されたこのＡＳのＵＲＩが“バイパス＝ＹＥＳ”パラメータを含むので、それをバイパスすることを決定する。このために、Ｓ−ＣＳＣＦサーバＳは、“Ｒｏｕｔｅ”ヘッダから、転送ＡＳのＵＲＩ及びＳ−ＣＳＣＦサーバＳのＵＲＩを削除すると共に、その場合に、このように修正された“逆ＩＮＶＩＴＥ（re-INVITE）リクエスト”に経路指定手順を再度適用し、そのＵＲＩが“Ｒｏｕｔｅ”ヘッダにおける第１番目のＵＲＩであるＰ−ＣＳＣＦプロキシサーバＰＡに、“逆ＩＮＶＩＴＥ（re-INVITE）リクエスト”を送信する。

２２．Ｐ−ＣＳＣＦプロキシサーバＰＡは、“逆ＩＮＶＩＴＥ（re-INVITE）リクエスト”をＡに送信する。

２３、２４、２５、及び２６．Ａは、“逆ＩＮＶＩＴＥ（re-INVITE）リクエスト”を受け入れると共に、“２００ ＯＫ”レスポンスを送信する。このレスポンスは、“逆ＩＮＶＩＴＥ（re-INVITE）リクエスト”によってたどられた経路の逆の経路をたどる。

２７、２８、２９、３０．Ｂは、リクエストＡＣＫによって、この“２００ ＯＫ”レスポンスの受領を通知する。このリクエストは、転送ＡＳがバイパスされる、“逆ＩＮＶＩＴＥ（ｒｅ−ＩＮＶＩＴＥ）リクエスト”と同じ方法で、経路指定される。

Ａ：端末
Ｂ：端末
ＰＡ：ＡのＰ−ＣＳＣＦプロキシサーバ
ＰＢ：ＢのＰ−ＣＳＣＦプロキシサーバ
ＡＳ：アプリケーションサーバ
Ｓ：Ｓ−ＣＳＣＦサーバ

Claims (10)

1. ＳＩＰメッセージが信号伝達経路のノードを構成する中間エンティティを経由して経路指定されるべき電気通信ネットワークにおける経路指定方法であって、
   前記方法が、
   利用不可能な場合にはバイパスされ得る中間エンティティをバイパスするステップを含み、
   前記バイパスするステップが、予め通過されるべき順番に並べられたエンティティの識別子のリストを含むＳＩＰメッセージのヘッダ（“Ｒｏｕｔｅ”、“Ｖｉａ”）内のバイパスされるべき前記中間エンティティの識別子（ＵＲＩ）を消去し、前記リストにおける次の中間エンティティの識別子（ＵＲＩ）を指定することによって達成される
   ことを特徴とする方法。
2. 中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するステップを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記判定するステップが、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示すローカルデータを使用して実行される
   ことを特徴とする請求項２に記載の方法。
4. 前記判定するステップが、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示す外部データベースを調べることによって実行される
   ことを特徴とする請求項２に記載の方法。
5. 前記判定するステップが、バイパスされ得る前記中間エンティティの前記ＳＩＰメッセージの経路指定ヘッダにバイパスする指標を挿入することによって達成される
   ことを特徴とする請求項２に記載の方法。
6. 前記中間エンティティの前記バイパスする指標が、最初のリクエストメッセージを送信する送信元エンティティに対して、電気通信ネットワークにおける前記送信元エンティティの登録の間に伝送される
   ことを特徴とする請求項５に記載の方法。
7. 前記中間エンティティの前記バイパスする指標が、前記送信元エンティティに対して、最初のリクエストメッセージを送信する前に伝送される
   ことを特徴とする請求項６に記載の方法。
8. 電気通信ネットワークにおいてＳＩＰメッセージを経路指定するための、信号伝達経路のノードを構成するエンティティであって、
   前記エンティティが、中間エンティティが利用不可能な場合には、予め通過されるべき順番に並べられたエンティティの識別子のリストを含むＳＩＰメッセージのヘッダ（“Ｒｏｕｔｅ”、“Ｖｉａ”）内のバイパスされるべき前記中間エンティティの識別子（ＵＲＩ）を消去し、前記リストにおける次の中間エンティティの識別子（ＵＲＩ）を指定することができる、前記中間エンティティをバイパスするための手段を備える
   ことを特徴とするエンティティ。
9. 中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するための手段を備える
   ことを特徴とする請求項８に記載のエンティティ。
10. コンピュータプログラムであって、
    前記プログラムがコンピュータによって実行されるときに請求項１から請求項７のいずれか一項に記載の方法を実行するためのプログラム命令を含む
    ことを特徴とするコンピュータプログラム。

Images