説明

中間ノードが利用不可能な場合にSIPメッセージを経路指定する方法

SIPメッセージが信号伝達経路のノードを構成する中間エンティティを経由して経路指定されることを目的としている電気通信ネットワークにおける経路指定方法を提供する。本発明によれば、前記方法は、利用不可能な場合にはバイパスされ得る中間エンティティをバイパスするステップを含む。本発明は、IMSアーキテクチャに対する応用性を提供する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、信号伝達経路のノードを構成する中間エンティティを経由して経路指定されるべきSIPメッセージを経路指定する方法に関連する。
【背景技術】
【0002】
本発明は、メッセージが伝送中に通過しなければならない1つ以上の中間エンティティが、利用不可能であると共に、従って同じ信号伝達経路上の他のエンティティによってコンタクトされない可能性がある状況において、特に有利なアプリケーションを見い出す。
【0003】
電気通信ネットワークは、送信元エンティティと送信先エンティティとの間で伝送された信号伝達メッセージが伝送中に通過する様々な中間エンティティによって構成される。信号伝達メッセージは、例えば、メッセージ通信システム(messaging system)におけるメッセージの存在の通知のような、他の情報と共に、“コール設定”リクエスト(call set-up request)のような、送信元エンティティから送信先エンティティに対するコールに連結された情報を含む。
【0004】
これらの中間エンティティは、信号伝達メッセージを経路指定することから、特定のサービスを提供する目的で、ある種の情報を挿入するか、もしくは削除することのように、そのメッセージによって達成されるべき動作まで、非常に多様な役割を有することができる。
【0005】
セッション確立プロトコル(SIP:Session Initiation Protocol)は、最初は、IPネットワークにおけるマルチメディアセッションの設定、変更、及び終了を可能にする目的で、インターネット技術タスクフォース(IETF:Internet Engineering Task Force)によって定義される。SIPは、同様に、IP伝送に基づくネットワーク制御アーキテクチャのそれらの定義の枠組において、第3世代パートナーシッププロジェクト(3GPP:3rd Generation Partnership Project)及びTISPAN(Telecoms & Internet converged Services & protocols for Advanced Networks)のような、様々な標準化団体及びコンソーシアムによって採用された。それらのアーキテクチャは、IPマルチメディアサブシステム(IMS)アーキテクチャを含む。移動通信か、または固定通信かに拘らず、SIPの使命は、従って、動作中の公衆通信網に使用されるセッション設定プロトコルとして、自身を確立することである。
【発明の概要】
【発明が解決しようとする課題】
【0006】
他の信号伝達プロトコルと比較すると、SIPは、SIPメッセージそれ自身で経路指定情報を伝達する能力によって特徴付けられる。これは、セッションを開始すると共に、最初のリクエストと呼ばれる第1番目のリクエストが、それが通過しなければならないエンティティのアドレスを含むことができるからである。このデータは、ネットワークにおける登録の時か、もしくは他のメカニズムによって、送信元エンティティによって復元されて、セッションの根源である送信元エンティティによって最初のリクエストメッセージに入力される。最初のリクエストが送信されるときに、コールの宛先、ネットワークのアーキテクチャ、及びセッションに必要なサービスに応じて、セッションに対応する信号伝達経路が設定される。次のSIPリクエスト及びSIPレスポンスは、それらを経路指定するために必要なデータを全て含む。これは、他のプロトコルと比較した主要な差異点であって、それに関して経路指定は、本質的に、ネットワークのエンティティ内に含まれるテーブル、及びコールに連結された経路指定データを格納するコールに関与するエンティティに基づいている。
【0007】
リクエスト及びそれに対するレスポンスという2つのタイプのSIPメッセージがある。レスポンスは、関連するリクエストに対して、逆の経路をたどる。
【0008】
最初のリクエストと次のリクエストとの間では区別が行われる。次のリクエストは、送信元エンティティにより送信された最初のリクエストによって生成された同じSIPダイアログの一部である。いくらかの最初のリクエストのみが、SIPダイアログ、例えば“INVITE”メッセージを生成し得る。次のリクエストの経路、すなわちこのダイアログの一部である全てのリクエストが通過しなければならないネットワークのSIPエンティティのセットは、ダイアログを生成する最初のリクエストを送信する時に決定される。
【0009】
SIPの最初のリクエストメッセージは、リクエストの送信先エンティティのアドレスを含む“Request−URI”ヘッダを有する(ここで、URIは、“Uniform Resource Identifier”を表す。)。SIPリクエストは、そのリクエストが通過しなければならない中間エンティティである、目的地に達する前に通過されるべきエンティティの身元のリストを、先のものから順に、そしてURIの形で含む特定の“Route”ヘッダを任意に有することができる。
【0010】
中間のSIPエンティティ、一般的にはSIPプロキシは、最初のリクエストを受信すると、それを分析することを開始する。もしリクエストが“Route”ヘッダを含むならば、エンティティは、その場合に、このヘッダに含まれる第1番目のSIPエンティティを、自身がそれに対してリクエストを送信しなければならないエンティティであると見なす。もしそうでなければ、エンティティは、特定の経路指定メカニズムを使用して、“Request−URI”ヘッダから、それに対してリクエストが送信されなければならない次のエンティティを決定する。
【0011】
それが中間エンティティであるか否かに拘らず、あらゆるSIPエンティティは、“Route”ヘッダまたは追加のエンティティのURIを、現存する“Route”ヘッダに加え得る。この機能は、多くの用途を有している。例えば、それは、リクエストがそのエンティティを通過することを保証するために、コンタクトされたネットワークの第1番目のエンティティが、“Route”ヘッダに、リクエストを送信するエンティティのユーザに対して割り当てられたサービスの管理に関与するエンティティの識別子を加えることを可能にする。サービスの管理に関与するエンティティは、アプリケーションサーバ(AS:application server)として知られている。
【0012】
信号伝達経路内に留まることを望む、最初のリクエストが通過する中間のSIPエンティティは、最初のリクエストを次のノードに送信する前に、それらの識別子を、最初のリクエストの“Record−Route”ヘッダに挿入する。
【0013】
最初のリクエストを送信する時に“Record−Route”ヘッダに含まれる識別子は、次のリクエストの“Route”ヘッダにおいて反復される。これらのリクエストは、以下の方法において経路指定される。中間のSIPエンティティは、次のSIPリクエストを受信すると、それを分析することを開始する。もしリクエストが“Route”ヘッダを含むならば、その場合に、このエンティティは、このヘッダに含まれる第1番目のSIPエンティティを、自身がそれに対してリクエストを送信しなければならないエンティティであると見なす。もしそうでなければ、このエンティティは、“Request−URI”ヘッダに含まれるエンティティを、自身がそれに対してリクエストを送信しなければならないエンティティであると見なす。
【0014】
SIPリクエストを送信をする時に、通過される各エンティティは、そのアドレスを“Via”ヘッダに加える。従って、リクエストを送信するエンティティのアドレスを含んで、このヘッダは、通過されるSIPエンティティの全てのアドレスを順番に蓄積する。
【0015】
リクエストの送信先エンティティまたは中間エンティティであるエンティティが、リクエストに対するレスポンスを生成する場合に、エンティティは、リクエストの“Via”フィールドにおいて受信されたアドレスを含む“Via”ヘッダを、同じ順番でそれらの中に挿入する。このリクエストを受信する各エンティティは、もしそれが次のノードにそのリクエストを送信することを決定するならば、このレスポンスの“Via”ヘッダにおける第1番目であるアドレスに対してそれを送信する。
【0016】
一般的に言えば、中間エンティティは、その時々に、例えば機器故障または過負荷の場合に、アクセス可能ではないことがあり得る。そのような状況において、ネットワークは、あらゆるそのようなエンティティを伝送中に通過するべきであるメッセージが拒絶される方法か、またはメッセージがいずれにせよその送信先へ伝達されることを可能にするバイパス経路が発見される方法、の2つの方法で動作し得る。この動作は、特に、すなわちそれが必須か否かに拘らず、関係のあるエンティティの特性によって決まると共に、信号伝達メッセージタイプによって決まる。
【0017】
SIPは、一般的に、この選択肢を提供せず、そして、第1番目の解決法、すなわち、メッセージの拒絶だけを可能にする。
【0018】
従って、中間エンティティが、リクエストの“Route”ヘッダにおける第1番目のSIPエンティティがアクセス可能ではないと判定するとき、その場合に、たとえ、このアクセス不可能な中間エンティティを回避して、リクエストを、その送信先まで伝達することが望ましかったであろうとしても、そして、たとえ、それが作用したであろう処理動作から利益を得ることができないとしても、中間エンティティは、送信元エンティティに“故障”レスポンスを送信することができる。
【0019】
同様に、もし中間エンティティが、次のノードにSIPレスポンスを送信すると共に、そのアドレスがそのレスポンスの“Via”ヘッダにおける第1番目のアドレスであるSIPエンティティがアクセス可能ではないと判定するならば、たとえ、アクセス不可能な中間エンティティを回避して、このレスポンスを、その送信先へ伝達することが望ましかったであろうとしても、その場合に、中間エンティティは、そのレスポンスを送信することを中止すると共に、そのレスポンスに対応する処理もキャンセルすることができる。
【0020】
従って、たとえ、メッセージの信号伝達経路に位置する中間エンティティが利用可能ではないとしても、メッセージの拒絶が回避されることを可能にする技術に関する必要性が存在する。
【課題を解決するための手段】
【0021】
本発明は、SIPメッセージが信号伝達経路のノードを構成する中間エンティティを経由して経路指定されるべき電気通信ネットワークにおける経路指定方法であって、前記方法が、利用不可能な場合にはバイパスされ得る中間エンティティをバイパスするステップを含み、前記バイパスするステップが、通過されるべきエンティティの識別子のリストを含むSIPメッセージのヘッダ内のバイパスされるべき前記中間エンティティの識別子を消去することによって達成されることを特徴とする方法を提案することによって、この必要性に対処する。
【0022】
本発明は、従って、SIPメッセージが、たとえそれが“Route”または“Via”ヘッダに示された中間エンティティを伝送中に通過し得ないとしても、その目的地に達することを可能にするという利点を有する。もし、アクセス不可能なエンティティによって提供された機能が、システムの動作を訂正するために重要ではないならば、そして、リクエストまたはレスポンスが拒絶されるよりむしろそのエンティティを回避して、その目的地に到達することが望ましいならば、この機能は、非常に有益である。
【0023】
本発明の経路指定方法は、中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するステップを有利に含む。
【0024】
第1の実施例において、前記判定するステップは、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示すローカルデータを使用して実行される。
【0025】
第2の実施例において、前記判定するステップは、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示す外部データベースを調べることによって実行される。
【0026】
第3の実施例において、前記判定するステップは、バイパスされ得る前記中間エンティティの前記SIPメッセージの経路指定ヘッダにバイパスする指標を挿入することによって達成される。
【0027】
本発明は、SIPから著しく分岐しないということが理解され得る。それは、本発明の方法を実行する中間エンティティによる特定の機能の実装だけを必要とし、そのエンティティは、通常の方法で動作する他のSIPエンティティに包囲され得る。
【0028】
リクエストメッセージに関連する本発明の一実施例において、前記ヘッダは、送信元エンティティによって送信されたSIPリクエストメッセージの“Route”ヘッダである。
【0029】
この実施例の第1の変形において、前記中間エンティティの前記バイパスする指標は、最初のリクエストメッセージを送信する送信元エンティティに対して、電気通信ネットワークにおける前記送信元エンティティの登録の間に伝送される。使用されるヘッダは、その場合に、“登録(REGISTER)”メッセージの“Path”ヘッダと、“登録(REGISTER)”メッセージに対する“200 OK”レスポンスメッセージの“Service−Route”ヘッダである。
【0030】
この実施例の第2の変形において、前記中間エンティティの前記バイパスする指標は、前記送信元エンティティに対して、最初のリクエストメッセージを送信する前に伝送される。
【0031】
この実施例の第3の変形において、前記バイパスの指標は、最初のリクエストメッセージを送信する際に、前記中間エンティティによって、“Record−Route”ヘッダに挿入されると共に、前記“Record−Route”ヘッダは、前記最初のリクエストメッセージを送信するエンティティによって、前記最初のリクエストに対するレスポンスメッセージにおいて受信されると共に、前記送信元エンティティによって、次のリクエストメッセージの“Route”ヘッダに複写される。
【0032】
この実施例の第4の変形において、前記バイパスの指標は、最初のリクエストメッセージを送信する際に、前記中間エンティティ以外の中間エンティティによって、“Route”ヘッダに挿入される。
【0033】
レスポンスメッセージに関連する別の実施例において、前記ヘッダは、SIPリクエストメッセージの“Via”ヘッダである。
【0034】
本発明によれば、この実施例において、前記バイパスの指標は、前記中間エンティティによって、リクエストメッセージの“Via”ヘッダに挿入される。“Via”ヘッダは、その場合に、レスポンスを送信するエンティティによって、レスポンスメッセージに複写される。
【0035】
本発明は、同様に、電気通信ネットワークにおいてSIPメッセージを経路指定するための、信号伝達経路のノードを構成する中間エンティティであって、前記中間エンティティが、前記SIPメッセージの経路指定ヘッダに、もし前記エンティティが利用不可能である場合のバイパスの指標を挿入し得ることを特徴とする中間エンティティに関連する。
【0036】
本発明は、更に、電気通信ネットワークにおいてSIPメッセージを経路指定するための、信号伝達経路のノードを構成するエンティティであって、前記エンティティが、中間エンティティが利用不可能な場合には、通過されるべきエンティティの識別子のリストを含むSIPメッセージのヘッダ内のバイパスされるべき前記中間エンティティの識別子を消去することができる、前記中間エンティティをバイパスするための手段を備えることを特徴とするエンティティに関連する。
【0037】
本発明によれば、前記エンティティは、中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するための手段を備える。
【0038】
本発明は、更に、コンピュータプログラムであって、前記プログラムがコンピュータによって実行されるときに本発明の方法を実行するためのプログラム命令を含むことを特徴とするコンピュータプログラムに関連する。
【0039】
本発明は、最終的に、利用不可能な場合にはバイパスされ得る信号伝達経路内の中間エンティティをバイパスする指標を経路指定ヘッダ内に含むSIPメッセージを伝送することを特徴とする信号に関連する。
【図面の簡単な説明】
【0040】
【図1】IMSアーキテクチャネットワークにおけるSIPリクエストメッセージの経路指定方法を例証する図である。
【図2】図1のIMSネットワークのノードを構成する種々のエンティティの間の信号伝達メッセージの経路指定に関する本発明の方法の図である。
【発明を実施するための形態】
【0041】
限定しない例として提供される添付された図面を参照する以下の説明は、本発明が何から構成されるか、そしてそれは実行するためにどう減少され得るかについて説明する。
【0042】
図1は、IMSネットワークにおいて、送信元エンティティAによって送信先エンティティBに対して送信されたSIPリクエストメッセージの信号伝達経路を表す。これらのエンティティA及びBは、固定通信もしくは移動通信の電話端末であって、例えば端末Aは端末Bに対する電話コールを開始する。
【0043】
現在、IMSアーキテクチャは、基本的に、電話、テレビ電話、プレゼンス(presence)、及びインスタントメッセージングタイプのアプリケーションに関して定義される。
【0044】
図1のネットワークは、以下の、
・IMSネットワークにおける端末A及びBの第1番目の接触点であると共に、伝送ネットワークの資源との相互作用を管理するP−CSCF(Proxy-Call Server Control Function)プロキシサーバPA及びPBと、
・IMSネットワークにおける端末A、及び特に、それによって端末Aのユーザが1つ以上のサービスに加入するアプリケーションサーバに対するトリガポイント(trigger point)を管理するS−CSCF(Serving-Call Server Control Function)サーバS(S−CSCFサーバSは、端末AがIMSネットワークにおいて登録されるとき、端末Aに割り当てられる。)と、
・問題のサービス、例えばコール転送サービスに関連付けられたアプリケーションサーバ(AS)(アプリケーションサーバASは、加入されたサービスに関する全ての情報を含む。)と、
を有する2つの端末A及びBの間の様々な中間エンティティを備える。
【0045】
もし中間エンティティが、“Route”ヘッダを含む最初のSIPリクエストメッセージまたは次のSIPリクエストメッセージ、あるいは“Via”ヘッダを含むSIPレスポンスメッセージを受信するならば、それは、そのメッセージを、“Route”ヘッダまたは“Via”ヘッダにおいて示された信号伝達経路上の次のノードに送信しなければならない。しかしながら、もし次のノードが利用不可能であるので、そのノードがコンタクトされない可能性があるならば、中間エンティティは、それをバイパスすると共に、SIPメッセージを、関係のあるヘッダにおける更に次のノードに送信することを決定し得る。もしそのノードが同様にアクセス不可能であるならば、中間エンティティは、それをもバイパスすることを決定し得る。
【0046】
以下の3つのメカニズム、
・エンティティがコンタクトされない可能性があることを判定するメカニズムと、
・もしエンティティがコンタクトされない可能性がある場合、そのエンティティがバイパスされ得るか否かを判定するメカニズムと、
・SIPリクエストが発生した場合に、“Route”ヘッダに含まれるエンティティをバイパスするか、またはSIPレスポンスが発生した場合に、“Via”ヘッダに含まれるエンティティをバイパスするメカニズムと、
は区別され得る。
【0047】
SIPエンティティは、別のエンティティがコンタクトされない可能性があることを、以下の、
・2つのエンティティ間の物理的トランスポート層におけるアクティビティ検出(維持(keep alive))メカニズムによる方法(例えば、端末は、ネットワークにおけるそれらの存在を示すために“Hello”メッセージを定期的に送信すると共に、もし端末がそのようなメッセージをもはや送信していないならば、それは利用不可能であることが考えられる。)、及び、
・SIPリクエストまたはSIPレスポンスを送信しようと試みる時に、物理的トランスポート層を介して“故障”メッセージを送信することによる方法、
の2つの方法で判定し得る。
【0048】
別のエンティティが利用不可能であると判定したので、利用不可能なエンティティによるSIPメッセージの送信が必須か否かに応じて、中間エンティティは、その別のエンティティがバイパスされ得るか否かを識別しなければならない。例えば、コール転送機能は、端末Aと端末Bとの間に電話コールを設定して維持することに、必須ではない。同様に、もしこの機能に関与するアプリケーションサーバASが利用不可能になるならば、SIPリクエストメッセージ及びSIPレスポンスメッセージにとって、それをバイパスすることが可能でなければならない。
【0049】
コンタクトされない可能性がある別のエンティティがバイパスされるべきであるか否かを第1番目のエンティティが判定するために、様々な方法がある。
【0050】
第1の方法において、第1番目のエンティティは、ある状況下で、コンタクトされない可能性があるエンティティがバイパスされ得るか否かを第1番目のエンティティが見分けることを可能にするローカルデータを保持する。例えば、端末Aは、もしプロキシサーバPAが利用不可能であるならば、端末AがプロキシサーバPAをバイパスする権限を与えるデータを有する。
【0051】
第2の方法において、第1番目のエンティティは、同じ情報を獲得するために、外部のサーバまたはデータベースを調べる。
【0052】
本発明は、更に、それによって、コンタクトされない可能性があるエンティティがバイパスされ得るか否かに関する情報が、関係のあるSIPメッセージの“Route”ヘッダまたは“Via”ヘッダにおけるそのエンティティの識別子と関連付けられる別の方法を提案する。この情報は、利用不可能なエンティティのURIにおける、以下ではバイパスインジケータ(bypass indicator:バイパスの指標/バイパスする指標)と呼ばれる新しいパラメータに含まれる。バイパスパラメータは、以下の値、例えばイエスかノーの値を有することができる。このパラメータの欠如が示すのは、URIのこの拡張が適用できないということである。
【0053】
SIPレスポンスに関して、このパラメータは、コンタクトされない可能性があるエンティティによって、そのURIを対応するリクエストの“Via”ヘッダに挿入する場合に加えられ得る。
【0054】
リクエストに関して、バイパスインジケータは、コンタクトされない可能性があるエンティティのURIに、様々な方法で挿入され得る。・例えば、ネットワークにおいて送信元エンティティを登録する段階の間、バイパスパラメータで補強された中間エンティティのURIが、“登録”メッセージの“Path”ヘッダか、または“登録”メッセージに対する“200 OK”レスポンスメッセージにおける“Service−Route”ヘッダに挿入される。
【0055】
“Path”ヘッダは、端末に対する経路をURIのリストの形式で登録するために、端末の登録の段階の間に使用される。この情報は、その場合に、端末にアドレス指定された最初のリクエストの“Route”ヘッダ内にその端末に到達するための信号伝達経路を示すために、この端末を登録したS−CSCFプロキシサーバによって使用される。
【0056】
“Service−Route”ヘッダは、ユーザのサービスを管理するS−CSCFプロキシサーバSに到達するための経路を登録するために使用される。その経路は、その場合に、登録された端末によって送信される最初のリクエストがS−CSCFプロキシサーバに経路指定されるように、登録された端末によって送信される最初のリクエストの“Route”ヘッダに挿入される。“Service−Route”ヘッダは、“登録(REGISTER)”リクエストに応答して、端末を登録したプロキシによって送信された登録を承認する“200 OK”メッセージに挿入される。
【0057】
・もし前記URIが予め設定されるならば、バイパスインジケータは、“Route”ヘッダを構成するURIに含まれ得る。これらのURIは、最初のリクエストを送信するSIPエンティティによって加えられる。例えば、端末Aは、最初のリクエストメッセージが送信される前に端末Aに伝達された、予め設定されたエンティティのURIを、“Route”ヘッダに挿入するように構成され得る。
【0058】
・バイパスインジケータを加えた中間エンティティのURIは、最初のリクエストメッセージを送信する際に、前記中間エンティティによって、“Record−Route”ヘッダに挿入される。この“Record−Route”ヘッダは、その場合に、最初のリクエストメッセージを送信するエンティティによって、最初のリクエストに対するレスポンスメッセージにおいて受信されると共に、送信元エンティティによって、次のリクエストメッセージの“Route”ヘッダに複写される。
【0059】
・バイパスインジケータは、最初のリクエストメッセージを送信する際に、関係のある中間エンティティ以外の中間エンティティによって、“Route”ヘッダに挿入される。
【0060】
バイパスパラメータが、メッセージが受信される状況及びメッセージタイプを考慮するための他の値によって補強され得ることに留意すべきである。
【0061】
例えば、
・messageType:そのメッセージがこのパラメータによって指定されたタイプのメッセージである場合にかぎり、エンティティはバイパスされ得る。
・earlyDialog:関係のあるメッセージがSIPアーリーダイアログ(SIP early dialogue)において受信される場合にかぎり、エンティティはバイパスされ得る。
・confirmedDialog:関係のあるメッセージがSIPコンファームドダイアログ(SIP confirmed dialogue)において受信される場合にかぎり、エンティティはバイパスされ得る。
【0062】
SIPコンファームドダイアログ、及びSIPアーリーダイアログは、文書RFC 3261において定義される。
【0063】
SIPリクエストメッセージを送信する際に、そのURIが“Route”ヘッダにおける第1番目のURIである中間エンティティをバイパスすることを、もしエンティティが決定するならば、そのエンティティは、その中間エンティティのURIを“Route”ヘッダから削除しなければならない。エンティティは、その場合に、このように修正されたリクエストに標準のSIP経路指定手順を適用する。もし“Route”ヘッダによって定義された信号伝達経路における次のノードが同様にアクセス不可能であるならば、この動作は繰り返され得る。従って、多くのノードが同時にバイパスされ得る。
【0064】
同様に、SIPレスポンスメッセージを送信する際に、そのURIが“Via”ヘッダにおける第1番目のURIである中間エンティティをバイパスすることを、もしエンティティが決定するならば、そのエンティティは、その中間エンティティのURIを“Via”ヘッダから削除しなければならない。エンティティは、その場合に、このように修正されたレスポンスに標準のSIP経路指定手順を適用する。もし“Via”ヘッダによって定義された信号伝達経路における次のノードが同様にアクセス不可能であるならば、この動作は繰り返され得る。従って、多くのノードが同時にバイパスされ得る。
【0065】
IMSアーキテクチャにおけるコール転送サービスを実行する本発明の例は、図2を参照して、以下で説明される。コール転送は、コールにおいて、このサービスに加入するユーザ(送信元エンティティ)によって、いつでも起動され得る。
【0066】
3GPPによって現在定義されたアプリケーションサーバASに関する起動メカニズムは、セッションまたはコールを開始する第1番目のリクエストによってのみ、ASの起動を可能にする。従って、コール転送アプリケーションサーバASがいつでもコールに介入することができなければならないと仮定すると、コール転送アプリケーションサーバASは、コールの開始と同時に、起動されると共に、転送サービスに対する加入者に影響を与えるあらゆるコールに関するSIP信号伝達経路に挿入されなければならない。コール転送アプリケーションサーバASがもはや利用可能ではないならば、このサーバを通過するコールが正常に伝送され続けることを可能にするために、サーバは、そのURIを最初のリクエストの“Record−Route”ヘッダに挿入する前に、パラメータ“バイパス=YES”を、そのURIに加える。従って、もしこのアプリケーションサーバASが、コールのセットアップの間に、またはコールがセットアップされたときに、機能しなくなる場合、S−CSCFは、それをバイパスすることになる。
【0067】
1.Aは、Bに対するコールを開始するために、“INVITE”リクエストメッセージを、“PA”と表示されると共にAが接続される、AのP−CSCFプロキシサーバに送信する。このメッセージは、“Route”ヘッダの中に、Aのサービスの実行に関与するS−CSCFサーバSのURI、及びプロキシPAのURIを含む。エンティティPAは、端末AとS−CSCFサーバSとの間の信号伝達経路の一部分である中間エンティティである。
【0068】
2.P−CSCFプロキシサーバPAは、P−CSCFプロキシサーバPAが次のリクエストを受信できるように、P−CSCFプロキシサーバPAのURIを含む“Record−Route”ヘッダを加えた後、“Route”ヘッダからP−CSCFプロキシサーバPAのURIを削除し、その後、リクエストを、そのURIが今このヘッダの第1番目のURIであるS−CSCFサーバSに送信する。
【0069】
3.S−CSCFサーバSは、Aが、コール転送サービスに加入すると共に、このサービスを提供することに関与するエンティティASを起動することを決定する、と判定する。S−CSCFサーバSは、転送ASを通過した後でリクエストがS−CSCFサーバSに戻るようにするために、“INVITE”リクエストを転送ASに送信する前に、S−CSCFサーバS自身のURIを従えている転送ASのURIを、“INVITE”リクエストの“Route”ヘッダに加える。
【0070】
4.転送ASは、そのコールの信号伝達経路の中に留まると共に、Aが起動する転送サービスを提供することができるように、転送ASのURIを“Record−Route”ヘッダに加えて、“INVITE”リクエストを、そのURIが“Route”ヘッダにおける次のURIであるS−CSCFサーバSに返信する。“転送”ASのURIは、もし転送ASがコンタクト不可能状態になるならば、このASがバイパスされ得ることを示すために、パラメータ“バイパス=YES”を含む。
【0071】
5.S−CSCFサーバSは、“INVITE”リクエストメッセージを、“PB”と表示されると共にBが接続される、BのP−CSCFプロキシサーバに送信する前に、S−CSCFサーバSのURIを“Record−Route”ヘッダに加える。
【0072】
6.P−CSCFプロキシサーバPBは、“INVITE”リクエストをBに送信する前に、P−CSCFプロキシサーバPBのURIを“Record−Route”ヘッダに加える。
【0073】
7、8、9、10、11、及び12.BはAからのコールを受け入れると共に、“200 OK”レスポンスメッセージを送信する。このレスポンスは、“INVITE”リクエストを送信する際に“Via”ヘッダにスタックされた、“INVITE”リクエストによってたどられた経路の逆の経路に沿って、Aに経路指定される。このレスポンスは、コールの中間エンティティをAに示すために、“INVITE”メッセージにおいてBが受信した“Record−Route”ヘッダを含む。
【0074】
13、14、15、16、17、18.Aは、“200 OK”レスポンスの受信を確認すると共に、リクエストACKを送信する。このリクエストは、最初の“INVITE”リクエストを送信する際に“Record−Route”ヘッダにスタックされた経路をたどる。Aは、“INVITE”リクエストに対するSIPの“200 OK”レスポンスの“Record−Route”ヘッダにおいて受信されたURIを含む“Route”ヘッダを、リクエストACKに挿入する。“200 OK”レスポンスは、他の緊急のレスポンス、特にBが警報を出されたことを示すリンギング(ringing)レスポンス180によって先行され得る。簡単化のために、これらのレスポンスと、リクエストACKの“Route”ヘッダと、“200 OK”レスポンスの“Via”ヘッダは、この図には表されていない。
【0075】
19.Bは、Aに“逆INVITE(re-INVITE)”リクエストメッセージを送信する。例えば、このリクエストは、例えばコーデックの変更のような、メディアセッションのパラメータを取り決めるために、またはセットアップされたセッションを更新(refresh)するために、送信され得る。
【0076】
20.P−CSCFプロキシサーバPBは、S−CSCFサーバSに対して、“Route”ヘッダに基づいて“逆INVITE(re-INVITE)リクエスト”を経路指定する。
【0077】
21.S−CSCFサーバSは、転送ASがもはやコンタクトされることができないと判定すると共に、“Route”ヘッダにおいて受信されたこのASのURIが“バイパス=YES”パラメータを含むので、それをバイパスすることを決定する。このために、S−CSCFサーバSは、“Route”ヘッダから、転送ASのURI及びS−CSCFサーバSのURIを削除すると共に、その場合に、このように修正された“逆INVITE(re-INVITE)リクエスト”に経路指定手順を再度適用し、そのURIが“Route”ヘッダにおける第1番目のURIであるP−CSCFプロキシサーバPAに、“逆INVITE(re-INVITE)リクエスト”を送信する。
【0078】
22.P−CSCFプロキシサーバPAは、“逆INVITE(re-INVITE)リクエスト”をAに送信する。
【0079】
23、24、25、及び26.Aは、“逆INVITE(re-INVITE)リクエスト”を受け入れると共に、“200 OK”レスポンスを送信する。このレスポンスは、“逆INVITE(re-INVITE)リクエスト”によってたどられた経路の逆の経路をたどる。
【0080】
27、28、29、30.Bは、リクエストACKによって、この“200 OK”レスポンスの受領を通知する。このリクエストは、転送ASがバイパスされる、“逆INVITE(re−INVITE)リクエスト”と同じ方法で、経路指定される。
【符号の説明】
【0081】
A:端末
B:端末
PA:AのP−CSCFプロキシサーバ
PB:BのP−CSCFプロキシサーバ
AS:アプリケーションサーバ
S:S−CSCFサーバ

【特許請求の範囲】
【請求項1】
SIPメッセージが信号伝達経路のノードを構成する中間エンティティを経由して経路指定されるべき電気通信ネットワークにおける経路指定方法であって、
前記方法が、
利用不可能な場合にはバイパスされ得る中間エンティティをバイパスするステップを含み、
前記バイパスするステップが、通過されるべきエンティティの識別子のリストを含むSIPメッセージのヘッダ(“Route”、“Via”)内のバイパスされるべき前記中間エンティティの識別子(URI)を消去することによって達成される
ことを特徴とする方法。
【請求項2】
中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するステップを含む
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記判定するステップが、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示すローカルデータを使用して実行される
ことを特徴とする請求項2に記載の方法。
【請求項4】
前記判定するステップが、エンティティにより、前記中間エンティティがバイパスされ得るか否かを示す外部データベースを調べることによって実行される
ことを特徴とする請求項2に記載の方法。
【請求項5】
前記判定するステップが、バイパスされ得る前記中間エンティティの前記SIPメッセージの経路指定ヘッダにバイパスする指標を挿入することによって達成される
ことを特徴とする請求項2に記載の方法。
【請求項6】
前記中間エンティティの前記バイパスする指標が、最初のリクエストメッセージを送信する送信元エンティティに対して、電気通信ネットワークにおける前記送信元エンティティの登録の間に伝送される
ことを特徴とする請求項5に記載の方法。
【請求項7】
前記中間エンティティの前記バイパスする指標が、前記送信元エンティティに対して、最初のリクエストメッセージを送信する前に伝送される
ことを特徴とする請求項6に記載の方法。
【請求項8】
電気通信ネットワークにおいてSIPメッセージを経路指定するための、信号伝達経路のノードを構成する中間エンティティであって、
前記中間エンティティが、前記SIPメッセージの経路指定ヘッダに、もし前記エンティティが利用不可能である場合のバイパスの指標を挿入し得る
ことを特徴とする中間エンティティ。
【請求項9】
電気通信ネットワークにおいてSIPメッセージを経路指定するための、信号伝達経路のノードを構成するエンティティであって、
前記エンティティが、中間エンティティが利用不可能な場合には、通過されるべきエンティティの識別子のリストを含むSIPメッセージのヘッダ(“Route”、“Via”)内のバイパスされるべき前記中間エンティティの識別子(URI)を消去することができる、前記中間エンティティをバイパスするための手段を備える
ことを特徴とするエンティティ。
【請求項10】
中間エンティティが利用不可能な場合にはバイパスされ得るか否かを判定するための手段を備える
ことを特徴とする請求項9に記載のエンティティ。
【請求項11】
コンピュータプログラムであって、
前記プログラムがコンピュータによって実行されるときに請求項1から請求項7のいずれか一項に記載の方法を実行するためのプログラム命令を含む
ことを特徴とするコンピュータプログラム。
【請求項12】
利用不可能な場合にはバイパスされ得る信号伝達経路内の中間エンティティをバイパスする指標を経路指定ヘッダ内に含むSIPメッセージを伝送することを特徴とする信号。

【図1】
image rotate

【図2】
image rotate


【公表番号】特表2010−507269(P2010−507269A)
【公表日】平成22年3月4日(2010.3.4)
【国際特許分類】
【出願番号】特願2009−531892(P2009−531892)
【出願日】平成19年10月15日(2007.10.15)
【国際出願番号】PCT/FR2007/052159
【国際公開番号】WO2008/047037
【国際公開日】平成20年4月24日(2008.4.24)
【出願人】(591034154)フランス・テレコム (290)
【Fターム(参考)】