(57)【要約】【課題】呼リクエスト（SIP メッセージ）のループを防止する。【解決手段】本発明の一態様としてのSIPサーバは、SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信する受信手段と、前記第１の呼リクエストに所定フラグが含まれているか否かを検査する検査手段と、前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成する呼リクエスト生成手段と、前記第２の呼リクエストに前記所定フラグを挿入するフラグ挿入手段と、前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信する呼リクエスト送信手段と、前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返すエラーメッセージ返信手段と、を備える。【選択図】図４
2008166929.tif 000002
【特許請求の範囲】
【請求項１】
SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信する受信手段と、
前記第１の呼リクエストに所定フラグが含まれているか否かを検査する検査手段と、
前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成する呼リクエスト生成手段と、
前記第２の呼リクエストに前記所定フラグを挿入するフラグ挿入手段と、
前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信する呼リクエスト送信手段と、
前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返すエラーメッセージ返信手段と、
を備えたSIPサーバ。
【請求項２】
前記第１または第２の呼リクエストは、SIPに規定されたSUBSCRIBEメッセージであることを特徴とする請求項１に記載のSIPサーバ。
【請求項３】
前記フラグ挿入手段は、前記第１の呼リクエストの呼と第２の呼リクエストの呼とがそれぞれ異なるとき前記所定フラグを挿入し、同じときは前記所定フラグを挿入しないことを特徴とする請求項１または２に記載のSIPサーバ。
【請求項４】
前記フラグ挿入手段は、前記第１および第２の呼リクエストに含まれる、SIPに規定されたCall-IDおよびFromタグの組がそれぞれ同一であるとき前記所定フラグを挿入せず、前記Call-IDおよび前記Fromタグの少なくとも一方が異なるときは前記所定フラグを挿入することを特徴とする請求項３に記載のSIPサーバ。
【請求項５】
複数の着呼先を２つ以上のグループに分けて記憶するグループ記憶手段をさらに備え、
前記呼リクエスト生成手段は、前記第１の呼リクエストの着呼先がグループを示すとき、該グループに属する各着呼先についてそれぞれ前記第２の呼リクエストを生成し、
前記呼リクエスト送信手段は、各前記第２の呼リクエストをそれぞれ対応する着呼先のSIP対応装置に送信する、
ことを特徴とする請求項１ないし４のいずれか一項に記載のSIPサーバ。
【請求項６】
SIPサーバにおいて実行する通信方法であって、
SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信し、
前記第１の呼リクエストに所定フラグが含まれているか否かを検査し、
前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成し、
前記第２の呼リクエストに前記所定フラグを挿入し、
前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信し、
前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返す、
ことを特徴とする通信方法。
【請求項７】
SIPサーバにおいて実行するプログラムであって、
SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信するステップと、
前記第１の呼リクエストに所定フラグが含まれているか否かを検査するステップと、
前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成するステップと、
前記第２の呼リクエストに前記所定フラグを挿入するステップと、
前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信するステップと、
前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返すステップと、
を備えたプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、SIP（Session Initiation Protocol ）サーバ、通信方法およびプログラムに関し、たとえば呼リクエスト（SIP リクエスト）を受信し、新たなSIP リクエストを生成および送信するSIPサーバに関する。
【背景技術】
【０００２】
SIP（Session Initiation Protocol ）は、経由するノードがそれぞれ宛先を決定しながら、最終的な宛先へとメッセージを転送する方式を採用している。そのため、メッセージ転送の過程で、宛先の選択に問題があると、同じメッセージが繰り返し同じところを通るループの状態が発生するおそれがある。そこでSIP では、Via ヘッダを用いたループ検出方法が規定されている。
【０００３】
SIP メッセージのVia ヘッダは、経由したノードのIP アドレスと、転送する際に生成されるSIP トランザクションのID とを含んでいる。SIP プロキシを介したSIP メッセージの中継を行っている場合、Via ヘッダは、中継の度にそれまで一番上にあったVia ヘッダの上に挿入される。Via ヘッダのIP アドレスを見ることで、同じメッセージが同じノードを２回以上経由していることがわかる。しかし、IP アドレスだけでループを判定することはできず、前回中継したときと中継元、中継先が同じであることを確かめる必要がある。そこでプロキシは、トランザクションのID をループ検出可能なように生成することができる。たとえばRFC3261 では、リクエストURI、コールID、From タグ、To タグ、CSeq ヘッダ、一番上のVia ヘッダのIP アドレスから求めたハッシュ値を使うことを推奨している。ループが発生している場合、一度中継して戻ってきたメッセージの上記のヘッダは、前回中継したときと同じ値になっているため、トランザクションID を計算すると、前回中継した際にVia ヘッダに挿入した値と同じになるはずである。これによってループを検出することができる。
【０００４】
Via ヘッダを用いたループの検出は、あくまでもプロキシがSIP メッセージに挿入するVia ヘッダにループ検出可能なトランザクションID を指定した場合にのみ可能になり、ループ検出を考慮したトランザクションID の生成を行わないプロキシでは、ループを検出できない。
【０００５】
RFC3261 により規定されるSIP プロキシの挙動と異なる処理を行ってメッセージを中継するサーバを、一般にB2BUA（Back-To-Back User Agent ）と呼ぶ。B2BUA は、中継するSIP メッセージ中のSIP プロキシが書き換えない部分についても変更して中継する。
【０００６】
例えば、B2BUA の中にはSDP（Session Description Protocol ）などのメッセージのボディを書き換えるものがある。これは、メディアゲートウェイなどを介した通信を端末から透過的に利用するためのもので、本来は端末のIP アドレスが含まれている部分をメディアゲートウェイのIP アドレスに書き換える。
【０００７】
B2BUA に分類されるサーバにはその用途に応じてさまざまなものがあり、メッセージを中継する方法も実装によってさまざまである。メディアゲートウェイの利用を目的としたSDP の書き換え以外に、多くのB2BUA でCall-ID、From タグ、To タグ、Via ヘッダ、CSeq ヘッダ、Contact ヘッダの書き換えが行われる。B2BUA がこれらのヘッダを書き換える主な理由は、B2BUA を挟んで中継元のIP アドレスやユーザー情報が中継先に伝わることを防ぐためである。
【０００８】
SIP メッセージを受信し、新たなメッセージを生成・送信するサーバとしてプレゼンスサーバがある。プレゼンスサーバは呼を中継しないが、利用者と呼ばれる端末からの要求に応じて、通知者と呼ばれる端末のステータス情報（プレゼンス情報）を利用者の代わりに取得し、利用者に通知する。
【０００９】
プレゼンスサーバは、利用者からのプレゼンス情報取得を要求するSUBSCRIBE リクエストを受けて、通知者に、プレゼンス情報のアップロードを要求するSUBSCRIBE リクエストを送信する。プロキシのようにメッセージを中継するのではなく、利用者とプレゼンスサーバ、プレゼンスサーバと通知者の間はそれぞれ個別の呼として処理される。
【００１０】
プレゼンスサーバからのSUBSCRIBE リクエストを受信した通知者は、自身のプレゼンス情報をNOTIFY リクエストでプレゼンスサーバに通知する。通知者からのNOTIFY リクエストを受けたプレゼンスサーバはさらに利用者にNOTIFY リクエストを送信し、通知者のプレゼンス情報を通知する。
【００１１】
通知者は、自らPUBLISH リクエストをプレゼンスサーバに送信し、自身のプレゼンス情報をあらかじめプレゼンスサーバにアップロードしておくこともできる。あらかじめプレゼンス情報がアップロードされている場合、プレゼンスサーバは、SUBSCRIBE リクエストで通知者に問い合わせることをせず、アップロードされているプレゼンス情報を利用者に通知する。
【非特許文献１】RFC3261（タイトル： SIP: Session Initiation Protocol関連のある章： 7、8、12、13、16  著者： J. Rosenberg、H. Schulzrinne、G. Camarillo、A. Johnston、J. Peterson、R. Sparks、M. Handley、E. Schooler）
【非特許文献２】RFC3265（タイトル： Session Initiation Protocol (SIP)-Specific Event Notification関連のある章： 1、3、4  著者： A. B. Roach）
【非特許文献３】RFC4662（タイトル： A Session Initiation Protocol (SIP) Event Notification  Extension for Resource Lists  関連のある章：1、3、4、5  著者： A. B. Roach、B. Campbell、J. Rosenberg）
【発明の開示】
【発明が解決しようとする課題】
【００１２】
B2BUA が行うメッセージの変更にはさまざまなものがあるが、SIP のループ検出機構を機能するためには、少なくとも呼を識別するダイアログID（コールID、From タグ、To タグの組み）が中継されても変化せずに保存されていることが前提となる。これは、SIP 端末やSIP プロキシ、B2BUA が未知のダイアログID を含むSIP メッセージを受信した場合に、新しい呼のメッセージとして処理するためで、仮にB2BUA がダイアログID 以外の部分を書き換えずにSIP メッセージを中継したとしても、書き換えられたメッセージを受信したノードでループ検出は行われない。また、ループ検出を行おうとした場合でも、RFC3261 で推奨されているようなSIP メッセージの一部からトランザクションID を計算する手法では、トランザクションID の計算結果が一致しないため、ループの検出はできない。従って、少なくともダイアログID を書き換えてSIP メッセージを中継するB2BUA に関しては、SIP の標準的なループ検出手法は適用できない。
【００１３】
ダイアログID が変化することによってループ検出ができなくなる問題は、プレゼンスサーバにも言える。プレゼンスサーバは、利用者から受信したSUBSCRIBE リクエストとは別の呼で通知者に問い合わせをするため、問い合わせのSUBSCRIBE リクエストがさらに別のプレゼンスサーバを介して戻ってきた場合にプレゼンスサーバは以前に自分が送信したSUBSCRIBE リクエストであることを認識できない。
【００１４】
ループを防ぐために、B2BUA やプレゼンスサーバで、事前に与えられた情報を元に送信するメッセージを宛先によって制限することが考えられる。しかし、全てのノードについて、ループの可能性の有無を把握することはできない。加えて、メッセージの宛先はSIP URI で表現されるが、SIP URI からその機器の種類や役割を判断できない。そのため、送信時に逐次送信の可否を判断することもできない。
【００１５】
本発明は、呼リクエスト（SIP メッセージ）のループを防止できるようにしたSIPサーバ（たとえばB2BUAまたはプレゼンスサーバ）、通信方法およびプログラムを提供する。
【課題を解決するための手段】
【００１６】
本発明の一態様としてのSIPサーバは、
SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信する受信手段と、
前記第１の呼リクエストに所定フラグが含まれているか否かを検査する検査手段と、
前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成する呼リクエスト生成手段と、
前記第２の呼リクエストに前記所定フラグを挿入するフラグ挿入手段と、
前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信する呼リクエスト送信手段と、
前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返すエラーメッセージ返信手段と、
を備える。
【００１７】
本発明の一態様としての通信方法は、
SIPサーバにおいて実行する通信方法であって、
SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信し、
前記第１の呼リクエストに所定フラグが含まれているか否かを検査し、
前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成し、
前記第２の呼リクエストに前記所定フラグを挿入し、
前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信し、
前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返す、
ことを特徴とする。
【００１８】
本発明の一態様としてのプログラムは、
SIPサーバにおいて実行するプログラムであって、
SIP（Session Initiation Protocol）対応装置から第１の呼リクエストを受信するステップと、
前記第１の呼リクエストに所定フラグが含まれているか否かを検査するステップと、
前記所定フラグが含まれていないとき、前記第１の呼リクエストから新たな第２の呼リクエストを生成するステップと、
前記第２の呼リクエストに前記所定フラグを挿入するステップと、
前記第２の呼リクエストを前記第１の呼リクエストにより指定されるSIP対応装置に送信するステップと、
前記所定フラグが含まれているとき、前記第１の呼リクエストの送信元である前記SIP対応装置にエラーメッセージを返すステップと、
を備える。
【発明の効果】
【００１９】
本発明により、呼リクエスト（SIP メッセージ）のループを防止できる。
【発明を実施するための最良の形態】
【００２０】
図１は、本発明にしたがったSIP サーバの典型的な構成の一例を示すブロック図である
このSIP サーバは、フラグ検査部１１と、メッセージ処理部１２と、フラグ挿入部１３とを備える。フラグ検査部１１は、受信手段と、検査手段とを含んでいる。メッセージ処理部１２は、呼リクエスト生成手段と、エラーメッセージ返信手段とを含んでいる。フラグ挿入部１３は、呼リクエスト送信手段を含んでいる。
【００２１】
フラグ検査部１１は、SIP対応装置（SIP端末または他のSIPサーバ）から受信したSIP メッセージに所定フラグ（ループ検出不可を示すフラグ）が挿入されているかを検査する。ここでのSIPメッセージは、SIPリクエスト（第１の呼リクエスト）である。SIPメッセージに所定フラグが挿入されている場合は、エラーレスポンスを上記他のSIPサーバに返す（後に明らかにされるように所定フラグが挿入されているのはSIPサーバからのSIPメッセージのみでSIP端末からのSIPメッセージには含まれていない）。所定フラグが挿入されていない場合には、SIP メッセージをメッセージ処理部１２に渡す。フラグ検査部１１はメッセージ処理部１２に、受信したSIP メッセージだけでなくSIP メッセージを受信したネットワークインターフェースや受信したポート番号などメッセージ受信に関する情報を渡してもよい。
【００２２】
フラグ検査部１１からの入力を受けて、メッセージ処理部１２ではSIP メッセージを処理し、送信するSIP メッセージを生成し、生成したSIPメッセージをその送信先アドレス（着呼先アドレス）とともにフラグ挿入部１３に渡す。SIP メッセージと送信先の組は1つとは限らず、複数の宛先に異なるSIP メッセージを送信する場合、複数のSIP メッセージと送信先アドレスとの組をフラグ挿入部１３に渡し、それぞれの組について、フラグ挿入部で処理される。送信先は、受信されたSIPメッセージから求めることができる。送信先（着呼先）は、SIP対応装置（SIP端末・SIPサーバ）である。メッセージ処理部１２からフラグ挿入部１３に渡す送信先アドレスは、IP アドレスだけでなく、送信に必要なその他の情報を含んでもよい。例えば、送信先ポート番号、使用するトランスポート層プロトコルを含んでもよい。
【００２３】
ここでメッセージ処理部１２の動作は、B2BUA の場合、B2BUA の目的に応じた処理を行う。プレゼンスサーバの場合は、RFC3265 に規定される処理を行う。プレゼンスサーバの場合、メッセージ処理部１２の動作は、RFC3265 に規定される範囲に限定されるものではなく、その他の拡張仕様に従ってSIP メッセージを処理してもよい。
【００２４】
フラグ挿入部１３は、メッセージ処理部１２から渡されたSIPメッセージ（第２の呼リクエスト）に所定フラグを挿入して、メッセージ処理部１２から渡された送信先アドレスに、所定フラグが挿入されたSIPメッセージを送信する。すなわち、メッセージ処理部１２から渡されたSIPメッセージの全てに所定フラグを挿入する。または、以下のように特定のSIPメッセージにのみ所定フラグを挿入することもあり得る。
【００２５】
SIPサーバから受信されるSIP メッセージと、メッセージ処理部１２により生成されるSIP メッセージとの２つのSIP メッセージに含まれるダイアログIDを比較する。ダイアログIDは、呼を識別するIDであり、通常は、SIPに規定されたCall-ID、Fromタグ、Toタグの組であるとされるが、本実施形態では、SIPリクエストに含まれるCall-IDおよびFromタグの組を指すものとする。2つのSIP メッセージ間でダイアログID が異なっているときは、メッセージ処理部１２により生成されたSIP メッセージに所定フラグを挿入し、所定フラグが挿入されたSIP メッセージを送信先アドレスに従って送信する。一方、２つのSIPメッセージ間でダイアログIDが一致するときは、SIPメッセージに所定フラグを挿入することなく、送信先アドレスに従って送信する。ただし、２つのSIP メッセージ間のダイアログID が一致するときでも、ダイアログID 以外のRFC3261 で規定されるループ検出ができない変更が加えられていると判断した場合には、SIP メッセージに所定フラグを挿入してもよい。
【００２６】
図２は、図１のSIPサーバの動作の一例を説明するフローチャートである。
【００２７】
SIPサーバは、SIP対応装置（SIP端末または他のSIPサーバ）から第１の呼リクエストを受信し（S1)、受信した第１の呼リクエストに所定フラグが含まれているか否かを検査する（S2）。
【００２８】
SIPサーバは、所定フラグが含まれていないとき（S2のNO）、第１の呼リクエストから新たな第２リクエストを生成し、生成した第２リクエストに所定フラグを挿入する（S3）。
【００２９】
SIPサーバは、生成した第２の呼リクエストを、上記第１の呼リクエストにより指定されるSIP対応装置（SIP端末・SIPサーバ）に送信する（S4）。
【００３０】
SIPサーバは、所定フラグが含まれているとき（S1のYES）、第１の呼リクエストの送信元である他のSIPサーバにエラーメッセージを返す（S5）。
【００３１】
図３は、図１のSIPサーバの動作の他の例を説明するフローチャートである。
【００３２】
SIPサーバは、SIP対応装置（SIP端末または他のSIPサーバ）から第１の呼リクエストを受信し（S1)、受信した第１の呼リクエストに所定フラグが含まれているか否かを検査する（S2）。
【００３３】
SIPサーバは、所定フラグが含まれていないとき（S2のNO）、第１の呼リクエストから新たな第２の呼リクエストを生成する（S6）。
【００３４】
SIPサーバは、第１の呼リクエストの呼と第２の呼リクエストの呼とが互いに異なるかどうかを検査する（S7）。すなわち第１の呼リクエストと第２の呼リクエストとに含まれるダイアログID（Call-ID,Fromタグ）が互いに異なるか同じかを検査する。ダイアログIDが第１の呼リクエストと第２の呼リクエストとで異なるとき第２の呼リクエストに所定フラグを挿入し（S7のYES、S8）、同一であるときは所定フラグを挿入しない。
【００３５】
SIPサーバは、第２の呼リクエストを、上記第１の呼リクエストにより指定されるSIP対応装置（SIP端末・SIPサーバ）に送信する（S9）。
【００３６】
SIPサーバは、所定フラグが含まれているとき（S2のYES）、第１の呼リクエストの送信元である他のSIPサーバにエラーメッセージを返す（S10）。
【００３７】
図４は、図１に示した構成をプレゼンスサーバに適用したとき例を示すブロック図である。すなわち図４は、図１に示したSIPサーバがプレゼンスサーバとして用いられるときの構成例を示す。
【００３８】
このプレゼンスサーバは、RFC3265 で規定される動作の他に、１つのSIP URI で複数の通知者をまとめて管理するグループ機能を備えている。例えば、利用者（購読者）が、宅内の機器を１つのグループに登録しておき、グループに対する情報取得要求をプレゼンスサーバに出力することにより、宅内の機器の状態を一括取得することができる。このようなプレゼンスサーバは、フラグ検査部１１、取得要求処理部２２、グループ管理部（グループ記憶手段）２１、フラグ挿入部１１、要求記憶部２３、プレゼンス情報処理部２４を備える。
【００３９】
フラグ検査部１１は、受信したSUBSCRIBE リクエスト（第１の呼リクエスト）のRequire ヘッダにfrom-ps オプションタグ（所定フラグ）が挿入されていた場合に、エラーレスポンス406 Not Acceptableを返す。フラグ検査部１１は、受信したSUBSCRIBE リクエストのRequire ヘッダにfrom-ps オプションタグ（所定フラグ）が挿入されていないときは、受信したSUBSCRIBEリクエストを取得要求処理部２２に渡す。
【００４０】
グループ管理部２１は、グループを表すSIP URI と、グループに属する通知者のSIP URIとの対応関係を保持する。通知者は、SIP端末または他のプレゼンスサーバまたはこれらの両方である。グループの作成と通知者の登録とは利用者が行い、通知者には任意のSIP URI を指定できる。SIP URI をキーにした問い合わせを受けると、SIP URI がグループを表すものであれば、グループに属するすべての通知者のSIP URI 一覧を返す。グループではない場合には、キーをそのまま返す。
【００４１】
取得要求処理部２２は、フラグ検査部１１から渡されたSUBSCRIBE リクエスト（第１の呼リクエスト）のToヘッダで示されるSIP URI を用いてグループ管理部２１に問い合わせを行い、SIP URIに示されるグループに属する通知者のSIP URI 一覧を得る。グループに属するすべての通知者ごとにダイアログID（Call-IDおよびFromタグ） を生成し、各通知者に対するSUBSCRIBE リクエスト（第２の呼リクエスト）を生成する。取得要求処理部２２は、利用者からのSUBSCRIBE リクエストのダイアログID と、各通知者に対するSUBSCRIBE リクエストのダイアログIDとを要求記憶部２３に登録する。
【００４２】
フラグ挿入部１３は、取得要求処理部２２により生成された各SUBSCRIBEリクエストのRequire ヘッダにfrom-ps オプションタグ（所定フラグ）を挿入して各通知者に通知する。または、フラグ挿入部１３は、プレゼンスサーバが受信したSUBSCRIBE リクエストと、取得要求処理部２２により生成されたSUBSCRIBE リクエストとの2 つのSUBSCRIBE リクエストのダイアログID を比較し、これらが互いに異なっているときのみ、通知者へのSUBSCRIBE リクエストのRequire ヘッダにfrom-ps オプションタグ（所定フラグ）を挿入するようにしてもよい。
【００４３】
プレゼンス情報処理部２４は、プレゼンスサーバから通知者に送信されたSUBSCRIBE リクエストに対して該通知者から送信されたNOTIFY リクエストを処理する。NOTIFY リクエストに含まれるプレゼンス情報をNOTIFY リクエストに含まれるダイアログID とともに要求記憶部２３に登録する。プレゼンス情報処理部２４は、要求記憶部２３に登録されている取得要求処理部２２により生成された各SUBSCRIBE リクエストに対して、すべての通知者からのNOTIFY リクエストが集まった場合、プレゼンス情報処理部２４は、RFC4662 に規定される方法により、問い合わせのあったグループに属するすべての通知者のプレゼンス情報を一括して利用者に対して通知する。
【００４４】
プレゼンス情報処理部２４は、通知者に送信されたSUBSCRIBE リクエストに対してエラー応答（エラーメッセージ）が返ってきた場合、エラーを返してきた通知者以外の通知者（すなわちNOTIFYリクエストを送信してきた通知者のみ）のプレゼンス情報を利用者に通知する。または、利用者からのSUBSCRIBE リクエスト全体をエラーとし、利用者からのSUBSCRIBE リクエストに対しエラー応答を返してもよい。
【００４５】
図５は、ループが生じない場合のプレゼンスサーバと利用者と通知者との間でのメッセージのシーケンス例を示す。この例では、プレゼンスサーバのグループ管理部２１には、以下のように、グループと通知者との対応付けが保持されているものとする。
【表１】
2008166929.tif 000003
【００４６】
以下の（１）〜（６）の説明では、メッセージ例として、SIP メッセージうち、スタートライン、From ヘッダ、To ヘッダ、コールID ヘッダ, Require ヘッダのみを示す。また、メッセージ例としては、リクエストのみ示し、プレゼンス情報を含むメッセージボディ、およびレスポンスメッセージの表記は省略する。
【００４７】
（１）利用者sip:watcher@example.com からプレゼンスサーバsip:ps.example.com へ、以下に示すプレゼンス情報取得要求（SUBSCRIBEリクエスト）が送信される（S11）。プレゼンス情報の取得が要求される対象はsip:group1@ps.example.com で識別されるグループである。
SUBSCRIBE sip:group1@ps.example.com
To:sip:group1@ps.example.com
From:sip:watcher@example.com;tag=1234           
Call-ID:abcd@5678.example.com                 
【００４８】
（２）プレゼンスサーバsip:ps.example.com から通知者sip:presentity1@example.com へ、以下に示すプレゼンス情報取得要求（SUBSCRIBEリクエスト）が送信される（S12）。通知者sip:presentity1@example.com はグループsip:group1@example.com に属し、プレゼンスサーバsip:ps.example.com のフラグ挿入部１３によってSUBSCRIBEリクエストのRequire ヘッダにfrom-ps オプションタグが挿入されている。
SUBSCRIBE  sip:presentity1@example.com
To:sip:presentity1@example.com
From:sip:ps.example.com;tag=0235
Call-ID:fetha@0375.example.com
Require:from-ps 
【００４９】
（３）プレゼンスサーバsip:ps.example.com から通知者sip:presentity2@example.com へプレゼンス情報取得要求（SUBSCRIBEリクエスト）が送信される（S13）。通知者sip:presentity2@example.com はグループsip:group1@example.com に属し、プレゼンスサーバsip:ps.example.com のフラグ挿入部１３によってSUBSCRIBEリクエストのRequire ヘッダにfrom-ps オプションタグが挿入されている。
SUBSCRIBE sip:presentity2@example.com
To:sip:presentity2@example.com
From:sip:ps.example.com;tag=9024 
Call-ID:asdlifj@2357.example.com
Require:from-ps 
【００５０】
（４）通知者sip:presentity1@example.com からプレゼンスサーバsip:ps.example.com へ以下に示すNOTIFYメッセージが送信される（S14）。すなわちプレゼンス情報が通知者からプレゼンスサーバにアップロードされる。
NOTIFY sip:ps.example.com
To:sip:ps.example.com;tag=0235
From:sip:presentity1@example.com;tag=3478
Call-ID:fetha@0375.example.com 
【００５１】
（５）通知者sip:presentity2@example.com からプレゼンスサーバsip:ps.example.com へ以下に示すNOTIFYメッセージが送信される（S15）。すなわちプレゼンス情報が通知者からプレゼンスサーバにアップロードされる。
NOTIFY sip:ps.example.com
To:sip:ps.example.com;tag=9024
From: sip:presentity2@example.com;tag=1247
Call-ID:asdlifj@2357.example.com 
【００５２】
（６）プレゼンスサーバsip:ps.example.com から利用者sip:watcher@example.com へ以下に示すNOTIFYメッセージが送信される（S16）。すなわち利用者にプレゼンス情報が通知される。
NOTIFY sip:watcher@example.com
To:sip:watcher@example.com;tag=1234
From:sip:group1@ps.example.com;tag=8273
Call-ID:abcd@5678.example.com 
【００５３】
図６は、ループが生じる場合のプレゼンスサーバと利用者と通知者との間でのメッセージのシーケンス例を示す。
【００５４】
この例では、プレゼンスサーバ１のグループ管理部には、以下のようにグループと通知者との対応付けが保持されているものとする。
【表２】
2008166929.tif 000004
【００５５】
またプレゼンスサーバ２のグループ管理部には、以下のようにグループと通知者との対応付けが保持されているものとする。
【表３】
2008166929.tif 000005
【００５６】
以下の（１１）〜（１６）の説明では、メッセージ例として、SIP メッセージうち、スタートライン、From ヘッダ、To ヘッダ、コールID ヘッダ, Require ヘッダのみを示す。また、リクエストのみ示し、プレゼンス情報を含むメッセージボディ、また、エラー応答以外のレスポンスメッセージの表記は省略する。
【００５７】
（１１）利用者sip:watcher@example.com からプレゼンスサーバsip:ps.example.com へ、以下に示すプレゼンス情報取得要求（SUBSCRIBEリクエスト）が送信される（S21）。プレゼンス情報の取得が要求される対象はsip:group1@ps1.example.com で識別されるグループである。
SUBSCRIBE sip:group1@ps1.example.com 
To:sip:group1@ps1.example.com
From:sip:watcher@example.com;tag=1234
Call-ID:abcd@5678.example.com 
【００５８】
（１２）プレゼンスサーバsip:ps1.example.com から通知者sip:presentity1@example.com へプレゼンス情報取得要求（SUBSCRIBEリクエスト）が送信される（S22）。通知者sip:presentity1@example.com はグループsip:group1@ps1.example.com に属し、プレゼンスサーバsip:ps1.example.com のフラグ挿入部によってSUBSCRIBEリクエストのRequire ヘッダにfrom-ps オプションタグが挿入される。
SUBSCRIBE sip:presentity1@example.com
To:sip:presentity1@example.com
From:sip:ps1.example.com;tag=0235 
Call-ID:fetha@0375.example.com
Require:from-ps 
【００５９】
（１３）プレゼンスサーバsip:ps1.example.com から通知者sip:group2@ps2.example.com へプレゼンス情報取得要求（SUBSCRIBEリクエスト）が送信される（S23）。グループsip:group2@ps2.example.comはグループsip:group1@ps1.example.com に属し、プレゼンスサーバsip:ps1.example.com のフラグ挿入部によってSUBSCRIBEリクエストのRequire ヘッダにfrom-ps オプションタグが挿入される。
SUBSCRIBE sip:group2@ps2.example.com
To:sip:group2@ps2.example.com
From:sip:ps1.example.com;tag=9024 
Call-ID:asdlifj@2357.example.com 
Require:from-ps 
【００６０】
（１４）プレゼンスサーバsip:ps2.example.comにおけるフラグ検査部は通知者sip:ps1.example.com からのSUBSCRIBE リクエストにおけるRequire ヘッダにfrom-ps オプションタグ（所定フラグ）を発見し、以下に示すエラーメッセージを返す（S24）。したがって、通知者sip:presentity2@example.comにはSUBSCRIBEリクエストは送信されない。
SIP/2.0 406 Not Acceptable
To:sip:group2@ps2.example.com;tag=0942
From:sip:ps1.example.com;tag=8953
Call-ID:zqckl@7244.example.com
Require:from-ps
【００６１】
（１５）通知者sip:presentity1@example.com からプレセンスサーバsip:ps1.example.com へ、以下に示すNOTIFYメッセージが送信される（S25）。すなわち通知者からプレゼンスサーバへプレセンス情報がアップロードされる。
NOTIFY sip:ps1.example.com
From:sip:ps1.example.com;tag=0235 
To:sip:presentity1@example.com;tag=0257 
Call-ID:fetha@0375.example.com 
【００６２】
（１６）ステップS24のエラー応答を受けて、プレセンスサーバsip:ps1.example.com から利用者sip:watcher@example.com へ、以下に示すエラーメッセージが返される（S26）。
SIP/2.0 406 Not Acceptable 
To:sip:group1@ps1.example.com;tag=5983
From:sip:watcher@example.com;tag=1234 
Call-ID:abcd@5678.example.com 
【００６３】
ここでは利用者sip:watcher@example.com からの要求全体をエラーとしているが、通知者presentity1@example.comから取得されたプレゼンス情報のみを返すようにしてもよい。または、通知者presentity1@example.comから取得されたプレゼンス情報を返すとともに、通知者presentity1@example.com以外の通知者に対する要求に対してはエラーが返された旨を返すようにしてもよい。
【００６４】
本実施形態によれば、プレゼンスサーバから送信するSIPメッセージには常に所定フラグを含めるようにするとともに、プレゼンスサーバにおいて所定フラグを含むSIPメッセージを受信した場合にはエラーを返すようにしたため、SIPメッセージは、2つ以上のサーバ（B2BUAまたはプレゼンスサーバなど）を経由できなくなる。この結果、SIP サーバが再度そのメッセージを中継することがなくなり、ループが発生しなくなる。
【００６５】
または、本実施形態によれば、プレゼンスサーバにおいて受信したSIPメッセージと、該プレゼンスサーバから送信するべきSIPメッセージとの間でダイアログIDに変化があるときは該送信するべきSIPメッセージに所定フラグを含めるとともに、所定フラグを含むSIPメッセージをプレゼンスサーバにおいて受信した場合にはエラーを返すようにしたため、SIPメッセージは、ダイアログID を変化させてSIP メッセージを中継するサーバ（B2BUAまたはプレゼンスサーバなど）を2つ以上経由できなくなる。よって、SIP サーバに、SIP サーバ自身が書き換えたダイアログID がさらに別のSIP サーバによって書き換えられて戻ってくることがなくなる。結果として、SIP サーバが再度そのメッセージを中継することがなくなり、ループが発生しなくなる。すなわち、従来においてループが発生する原因は、中継先SIP URI からは、中継先ノードがSIP サーバであるのかまたループの可能性があるのかを判断できないことにあり、ダイアログID を書き換えるSIP サーバを2つ以上経由してメッセージが戻ってくると、SIP サーバは以前に自分が送信したメッセージと認識できない。このため再度メッセージを送信してしまうことにある。これに対し本実施形態ではダイアログIDに変化があったSIPメッセージはそれ以上中継されないためループの発生を阻止することができる。
【００６６】
なお、図１、図４および図５のSIPサーバは、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、SIPサーバに含まれる各構成要素は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、SIPサーバは、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。
【００６７】
以上、具体的な手順を挙げながら、本発明の実施形態について説明を行った。なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。その一例は上記手順中においていくつか述べてきた。
【図面の簡単な説明】
【００６８】
【図１】本発明にしたがったSIP サーバの典型的な構成の一例を示すブロック図である。
【図２】図１のSIPサーバの動作の一例を説明するフローチャートである。
【図３】図１のSIPサーバの他の動作例を説明するフローチャートである。
【図４】図１に示した構成をプレゼンスサーバに適用したとき例を示すブロック図である。
【図５】ループが生じない場合のプレゼンスサーバと利用者と通知者との間でのメッセージのシーケンス例を示す。
【図６】ループが生じる場合のプレゼンスサーバと利用者と通知者との間でのメッセージのシーケンス例を示す。
【符号の説明】
【００６９】
１１：フラグ検査部
１２：取得要求処理部
１３：フラグ挿入部
２１：グループ管理部
２２：取得要求処理部
２３：要求記憶部
２４：プレゼンス情報処理部
【図１】
2008166929.tif 000006
【図２】
2008166929.tif 000007
【図３】
2008166929.tif 000008
【図４】
2008166929.tif 000009
【図５】
2008166929.tif 000010
【図６】
2008166929.tif 000011