JP2006254253A - セッション中継装置 - Google Patents

Abstract

【課題】セッション中継装置間の連携が頻繁に行われるようになると、呼制御メッセージの経路上で拡張処理が余分に実行されることがあり得る。そのような事態を避けるためには、セッション中継装置間で拡張処理を行う装置を決定するための一貫した方法が必要である。
【解決手段】セッション中継装置は、呼制御メッセージを受信するたびにそれが転送される経路に関する情報を計算する。呼制御メッセージに加えてその経路情報を拡張処理プログラムに渡すことで、その拡張処理を自セッション中継装置上で行うべきかどうかをセッション毎に決定する。また、拡張処理を実行したセッション中継装置は、そのことを他のセッション中継装置に通知するために、呼制御メッセージに処理状況を表す情報を追加する。
【選択図】図１

Description

本発明は、呼制御メッセージを転送するセッション中継装置を用いた、呼制御メッセージの転送される経路上で拡張処理を実行する装置及びシステムに関する。

近年、ブロードバンドの普及とＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話プロトコルの標準化が進んだことにより、ＩＰ電話が急速に普及している。それらＩＰ電話プロトコルの中で特に普及しているものは、インターネットの特性を考慮して設計されたＩＰ電話プロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）である。
ＳＩＰの最も単純な構成における構成要素は以下の３つである。本明細書では、実施例について説明する際にも以下の定義を用いる。

１つ目の構成要素はＳＩＰ ＵＡ（Ｕｓｅｒ Ａｇｅｎｔ）である。これはＳＩＰの呼制御メッセージであるＳＩＰメッセージを解釈できる通信端末である。
２つ目の構成要素はロケーションサーバである。これはＳＩＰ ＵＡを表す名前（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ；ＵＲＩなど）と、ＳＩＰ ＵＡのネットワークアドレスの対応関係を管理するサーバである。

ロケーションサーバは、ＳＩＰ ＵＡとＳＩＰプロクシを管理する。本明細書では、１つのロケーションサーバが管理するＳＩＰ ＵＡとＳＩＰプロクシの範囲のことを、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）におけるドメインと区別するために、各ロケーションサーバの「スコープ」と呼称する。ドメインとスコープの範囲は通常一致するが、１つのスコープが複数のドメインを含むなど、完全に一致しなくてもよい。

３つ目の構成要素はＳＩＰプロクシである。これはロケーションサーバ上の情報に基づいて、宛先のＳＩＰ ＵＡに向けてＳＩＰメッセージを転送するサーバである。ＳＩＰプロクシは必ずしも宛先のＳＩＰ ＵＡに直接ＳＩＰメッセージを転送する必要はなく、自身よりも宛先に近い他のＳＩＰプロクシへとＳＩＰメッセージを転送することもできる。

またＳＩＰプロクシは、ＳＩＰメッセージを受信した際に、時にはＳＩＰメッセージの転送以外の拡張処理を実行することがある。そのような拡張処理には、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）プロクシなどのメディア中継装置との連携、プレゼンスサーバとの連携、Ｗｅｂサーバとの連携、ログの記録、課金情報の記録、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御などがある。元々ＳＩＰはインターネット上のマルチメディア通信の基盤となる呼制御プロトコルとして考え出されたため、ＳＩＰプロクシは他のサーバと連携した拡張処理でも容易に実行できる。ただし、本発明の効果を奏する限り、拡張処理はここに挙げた処理でなくてもよい。
以上はＳＩＰプロクシにおける拡張処理の例だが、その他の呼制御プロトコルにおいても、呼制御メッセージの転送以外の拡張処理を実行するセッション中継装置は存在する。

以下では、呼制御メッセージを転送するセッション中継装置で、呼制御メッセージの転送以外の拡張処理を実行することによる課題を提示する。
現在では呼制御メッセージの転送以外の拡張処理を実行するセッション中継装置が、他の事業者の管理するセッション中継装置と連携することは稀であるが、今後事業者間での接続が増加するなどして、セッション中継装置間の連携が頻繁に行われるようになると、呼制御メッセージの経路上で拡張処理が重複して実行されたり、必要な拡張処理が実行されなかったりすることがあり得る。

ＳＩＰにおいて、セッション中継装置（ＳＩＰプロクシ）が、拡張処理としてメディア中継装置（ＲＴＰプロクシ）と連携した場合の例が図２１である。
この図は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間で呼制御メッセージ（ＳＩＰメッセージ１００）を交換する際の様子を示している。このとき、ＳＩＰプロクシ３−１はＳＩＰ ＵＡ２−１がＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）装置７−１の背後にあるためにＲＴＰプロクシ５−１と連携し、ＳＩＰプロクシ３−２はＳＩＰ ＵＡ２−２がＮＡＴ装置７−２の背後にあるためにＲＴＰプロクシ５−２と連携する。このように、ＳＩＰプロクシは他のＳＩＰプロクシが実行した拡張処理について知るための手段を持たないため、本来は経路上で一度だけ実行されれば十分なＲＴＰプロクシ連携を重複して実行してしまう。

そこで、このような事態を避けるためには、セッション中継装置間で、どのセッション中継装置が拡張処理を行うかを決定できる一貫した方法が必要である。以上の課題の内容は、ＳＩＰに限定されない。
また、本発明の効果を奏する限り拡張処理は上記の例のようなRTPプロクシとの連携処理でなくてもよい。

本発明では、各セッション中継装置のメモリ上に、呼制御メッセージが転送される経路に関する情報を計算するプログラムと、各ユーザ端末が必要とする拡張処理に関する情報を計算するプログラムを備える。また、これら２つのプログラムとは別に、各セッション中継装置のメモリ上に、拡張処理を行うプログラムを備える。

各セッション中継装置は、呼制御メッセージに加えて上記２つの情報を、拡張処理を行うプログラムに渡すことで、その拡張処理を自セッション中継装置上で行うべきかどうかをセッション毎に決定する。また、セッション中継装置は、拡張処理を実行したことを他のセッション中継装置に通知するために、呼制御メッセージに処理状況を表す情報を追加する。これにより、前記の目標を達成する。

経路上のセッション中継装置で拡張処理が行われる回数が最低限に抑えられることで、セッション中継装置での処理負荷が軽減され、呼制御メッセージを転送する際の遅延時間が短くなる。また、セッション中継装置での処理が外部サーバとの連携を伴う場合には、セッション中継装置だけではなく、外部サーバのトラフィック量削減にも繋がる。このようにして、ネットワーク全体の負荷が軽減される。

以下、実施例を図面に基づいて説明する。
図１−ａには、本実施例で想定している物理的な通信ネットワークの構成を模式的に示す。ＳＩＰ ＵＡ２−１としては通信機能を備えたＰＣや電話型端末のような固定端末の他、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）のような移動端末であっても良い。３−１はＳＩＰプロクシであり、ロケーションサーバ４−１の管理する情報に基づいて、ＳＩＰメッセージの経路を決定し、転送する。図１−ｂのＳＩＰサーバ５−１のように、ＳＩＰプロクシとロケーションサーバが一体であってもよい。上記ＳＩＰ ＵＡ２−１、ＮＡＴ装置７−１、ＳＩＰプロクシ３−１、ロケーションサーバ４−１およびＲＴＰプロクシ５−１は、互いに物理的な通信回線９を介して接続されている。ＳＩＰ ＵＡ２−１はＮＡＴ装置７−１を介して間接的に通信網１−１に接続されており、ＳＩＰ ＵＡ２−１はＳＩＰプロクシ３−１を経由してのみＳＩＰメッセージを送受信できるものとする。また、これらは同じスコープ１０−１に所属している。

スコープ１０−２のＳＩＰ ＵＡ２−２、ＮＡＴ装置７−２、ＳＩＰプロクシ３−２、ロケーションサーバ４−２およびＲＴＰプロクシ５−２も、スコープ１０−１と同様に、互いに物理的な通信回線９を介して接続されている。ＳＩＰ ＵＡ２−２はＮＡＴ装置７−２を介して間接的に通信網１−２に接続されており、ＳＩＰ ＵＡ２−２はＳＩＰプロクシ３−２を経由してのみＳＩＰメッセージを送受信できるものとする。

また、通信網１−１と通信網１−２は物理的な通信回線９を介して接続されている。
スコープ１０−１はロケーションサーバ４−１が管理する範囲、スコープ１０−２はロケーションサーバ４−２が管理する範囲というだけで、スコープの範囲は必ずしも物理的な位置によって制限されるものではない。しかし、図中では理解を助けるために、物理的な通信ネットワーク上の位置とスコープの範囲を一致させている。

実施例１から４のロケーションサーバは、従来のロケーションサーバが管理する情報に加えて、そのロケーションサーバが管理するスコープ内の各ＳＩＰ ＵＡが要求する拡張処理に関する情報も管理するものとする。実施例１では、ロケーションサーバ４−１は「ＳＩＰ ＵＡ２−１がＲＴＰプロクシ連携を要求する」という情報を管理し、ロケーションサーバ４−２は「ＳＩＰ ＵＡ２−２がＲＴＰプロクシ連携を要求する」という情報を管理しているものとする。

また、実施例１、２及び４のＲＴＰプロクシは、セッションを一意に特定する識別子（Ｃａｌｌ−ＩＤなど）をＳＩＰプロクシから受け取ると、そのセッションに対応するポート番号が割り当てられていなければ新たに割り当て、そしてそのポート番号をＳＩＰプロクシに送り返す、という単純なものであるとする。

実施例１では、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立するものとする。細い実線１００は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際のＳＩＰメッセージの流れを示したものである。ここではＳＩＰ ＵＡ２−１が発側（ＩＮＶＩＴＥを送信したＳＩＰ ＵＡ）、ＳＩＰ ＵＡ２−２が着側とする。また、破線１１０はＲＴＰストリームの流れを示したものである。

図５には、図１−ａに示したＳＩＰプロクシ３（ＳＩＰプロクシ３−１、ＳＩＰプロクシ３−２共通）の内部構成を機能展開して示したブロック図を示す。ＳＩＰプロクシ３はＩＦ３１を通してＳＩＰメッセージを送受信する。ＳＩＰプロクシ３の各プログラムはメモリ３３に格納されており、動作時にはＣＰＵ３２がデータパス３４を通してそれらを読み出して実行する。また、ＳＩＰプロクシ３の管理する各テーブルもメモリ３３に格納されており、ここから必要な情報を取り出し、書き込む。これらのテーブルは、ハードディスク等のストレージシステムで実現されるＤＢ装置に格納してもよい。

メモリ３３はセッション管理テーブル３３０、呼制御プログラム３３１、経路決定プログラム３３２、処理情報取得プログラム３３３、ＲＴＰプロクシ連携プログラム３３４、静的処理情報テーブル３３７を格納する。
セッション管理テーブル３３０は、ＳＩＰプロクシ３が現在扱っているセッションに関する情報を格納するテーブルである。それらの情報には各セッションの状態、セッションの識別子、発側と着側のＵＲＩ及びＣｏｎｔａｃｔアドレスなどがある。本特許では、セッション管理テーブル３３０は通常のＳＩＰプロクシが管理するこれらの情報に加えて、「経路タイプ」、「前ホップ」、「次ホップ」、そしてそのセッションで行った拡張処理に関する情報も格納するものとする。

経路タイプとは経路全体の特徴を表し、１つのスコープ内に閉じた経路（以下、「閉」）か、または複数のスコープを跨いだ経路（以下、「開」）かのいずれかである。ＳＩＰメッセージのＦｒｏｍヘッダに含まれるＵＲＩ（以下、発側ＵＲＩ）と、Ｔｏヘッダに含まれるＵＲＩ（以下、着側ＵＲＩ）から決定する。

前ホップとは、ＳＩＰプロクシ３に対するＳＩＰメッセージの送信元のことで、ＳＩＰプロクシ３と同じスコープに属するＳＩＰ ＵＡ（以下、自スコープＵＡ）、ＳＩＰプロクシ３と同じスコープに属する他のＳＩＰプロクシ（以下、自スコープＳＩＰプロクシ）、ＳＩＰプロクシ３とは異なるスコープに属するＳＩＰプロクシ（以下、他スコープＳＩＰプロクシ）の３通りである。そのいずれかは、ＳＩＰプロクシ３がそのＳＩＰメッセージの受信に用いたＮＮＩ（Ｎｅｔｗｏｒｋ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）またはＵＮＩ（Ｕｓｅｒ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）から決定する。

次ホップとは、ＳＩＰプロクシ３が次にＳＩＰメッセージを送信する送信先のことで、自スコープＵＡ、自スコープＳＩＰプロクシ、他スコープＳＩＰプロクシの３通りである。そのいずれかは、着側ＵＲＩから決定する。

そのセッションで行った拡張処理に関する情報とは、ＳＩＰプロクシ３がそれぞれの拡張処理について「実行」か「未実行」かを記録したものである。用途は後述する。
また以下の実施例１〜４では、セッション管理テーブル３３０は上記の情報を格納する領域に加えて、ロケーションサーバ４から取得した発側または着側（もしくはその両方）の情報をキャッシュする領域を持っているものとする。しかし本発明では、このようなキャッシュがなくてもよい。

呼制御プログラム３３１は、ＳＩＰメッセージの基本的な操作を行うプログラムである。経路決定プログラム３３２、処理情報取得プログラム３３３、そして拡張処理プログラム（ＲＴＰプロクシ連携プログラム３３４や、実施例３以降のプレゼンスサーバ連携プログラム３３５など）を呼び出す点以外は、既存のＳＩＰプロクシと同様の機能を提供する。

経路決定プログラム３３２は、呼制御メッセージが転送される経路に関する情報を計算するプログラムである。このプログラムは、ＳＩＰメッセージが転送される経路の経路タイプ、前ホップ、そして次ホップを計算する。

処理情報取得プログラム３３３は、各ＳＩＰ ＵＡが必要とする拡張処理に関する情報を計算するプログラムである。それらの情報には動的な情報と静的な情報がある。前者は各ＳＩＰ ＵＡ毎に異なる情報で、例えば「ＳＩＰ ＵＡが（ＮＡＴ装置の背後にいるために）ＲＴＰプロクシ連携を要求している」などの情報である。後者はスコープ内のＳＩＰ ＵＡに共通の情報で、例えば「スコープ内のＳＩＰ ＵＡが通話を開始したら、その状態を自動的に『通話中』に更新する」などの情報である。

ＲＴＰプロクシ連携プログラム３３４は拡張処理を行うプログラムの一種で、経路決定プログラム３３２と処理情報取得プログラム３３３の計算結果を受け取り、特定の条件を満たす場合のみＳＩＰプロクシ−ＲＴＰプロクシ間連携（以下、ＲＴＰプロクシ連携）を実行する。ＲＴＰプロクシ連携とは、ＲＴＰプロクシにポート番号の割り当てを要求し、割り当てられたポート番号を用いてＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージの内容を書き換えることで、ＳＩＰ ＵＡ間でやり取りされるＲＴＰパケットが必ずＲＴＰプロクシを経由するようにすることである。

静的処理情報テーブル３３７は、各ＳＩＰ ＵＡが必要とする拡張処理に関する情報の内、スコープ内の全ＳＩＰ ＵＡに共通する情報を格納するテーブルである。実施例１及び２では、このテーブルは特に何の情報も含まなくてもよい。
上述のように、拡張処理を実行するべきか判断するために必要な情報を計算するプログラムと、拡張処理を実行するプログラムが分離していることで、セッション中継装置に元々あるプログラムを修正することなく、拡張処理を実行するプログラムを容易に追加または削除できるようになる。

図１６は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際の動作の一例を示すシーケンス図である。以下では、図１６に示したシーケンス図及び図８〜１３に示したフローチャートを用いて、ＳＩＰメッセージが複数のＳＩＰプロクシを経由する際に、ＲＴＰプロクシ連携を実行するＳＩＰプロクシが動的に決定される様子を説明する。

ＳＩＰプロクシ３−１がＳＩＰ ＵＡ２−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ６０１）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２はＳＩＰメッセージがリクエストかどうか判断し（Ｓ１０１）、リクエストの場合はそれがＡＣＫかどうか判断する（Ｓ１０２）。この場合リクエストはＩＮＶＩＴＥであるため、まず経路タイプを「閉」に設定する（Ｓ１０３）。その後、発側ＵＲＩのドメインなどから、発側ＵＲＩに対応するＵＡ（以下、発側ＵＡ）が自スコープＵＡか他スコープＵＡかを判別する（Ｓ１０４）。ＳＩＰ ＵＡ２−１とＳＩＰプロクシ３−１は同じスコープに属するため（Ｓ１０５）、発側ＵＡの情報をロケーションサーバ４−１から取得する（Ｓ１０６）。これと同様に、着側ＵＲＩに対応するＵＡ（以下、着側ＵＡ）についても自スコープＵＡか他スコープＵＡかを判別する（Ｓ１０８）。ＳＩＰ ＵＡ２−２とＳＩＰプロクシ３−１は異なるスコープに属するため（Ｓ１０９）、経路タイプを「開」に設定する（Ｓ１１１）。

次に、経路決定プログラム３３２はリクエストの受信がＵＮＩ経由で行われたかＮＮＩ経由で行われたかを判別する（Ｓ１１７）。この判別は、ＩＮＶＩＴＥの送信元アドレスが、ＮＮＩとして事前に登録されているものかどうか比較するなどして行う。ＩＮＶＩＴＥの送信元アドレスはＳＩＰ ＵＡ２−１であるため、発側ＵＡ（自スコープＵＡ）を前ホップに設定する（Ｓ１１９）。

Ｓ１０８の結果から着側ＵＡが自スコープＵＡではないとわかっているため（Ｓ１２１）、経路決定プログラム３３２はＳＩＰ ＵＡ２−２へとＩＮＶＩＴＥを転送できるＳＩＰプロクシ３−２（他スコープＳＩＰプロクシ）を次ホップに設定する（Ｓ１２５）。そして、このセッション固有の情報として、経路タイプ、前ホップ、次ホップの情報（Ｓ６０４）をセッション管理テーブルに登録する（Ｓ１２６）。そして、経路タイプなどとは別に、ロケーションサーバから取得した情報のキャッシュをセッション管理テーブルに登録する（Ｓ１２７）。経路決定プログラム３３２は以上のようにして得た情報を、呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。
処理情報取得プログラム３３３は、自スコープに属するＳＩＰ ＵＡの情報のキャッシュをセッション管理テーブルから取得する（これはＳ１２７で登録されたものである）。本実施例ではキャッシュを利用しているが、キャッシュを利用しない場合はここで再びロケーションサーバにアクセスしてもよい。また、拡張処理に関する動的な情報を格納する専用のサーバがロケーションサーバ以外に存在する場合はそのサーバにアクセスしてもよい。スループットを重視する場合はキャッシュを利用し、ＳＩＰプロクシ上のメモリやディスク領域の節約を重視する場合はロケーションサーバや専用のサーバを利用することが望ましい。

この例では発側ＵＡが自スコープＵＡであるため（Ｓ２０１）、発側ＵＡの処理情報を取得し（Ｓ２０２）、着側ＵＡは他スコープＵＡであるため（Ｓ２０３）、特に何も行わない。その後、自スコープ内で共通の処理情報を静的処理情報テーブルから取得する（Ｓ２０５）。実施例１では静的処理情報テーブル３３７は何の情報も含まないため、静的な情報は何も取得できない。処理情報取得プログラム３３３は以上のようにして得た「発側ＵＡがＲＴＰプロクシ連携を要求する」という動的な情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。呼制御プログラム３３１はＲＴＰプロクシ連携プログラム３３４のような拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。

ＲＴＰプロクシ連携プログラム３３４は、前ホップまたは次ホップが自スコープＵＡか検査する（Ｓ３０１）。この例では前ホップが自スコープＵＡであるため、次に発側ＵＡまたは着側ＵＡがＲＴＰプロクシ連携を要求しているか検査する（Ｓ３０２）。この例では、Ｓ１０６にてロケーションサーバ４−１から取得した情報により、発側ＵＡであるＳＩＰ ＵＡ２−１がＲＴＰプロクシ連携を要求していることが分かるため、次の処理に進む。

この例では、受信したＳＩＰメッセージがＩＮＶＩＴＥであり（Ｓ３０４）、ＳＤＰを含んでいる（Ｓ３０５）。そのため、次に経路タイプが「開」かどうかを検査する（Ｓ３１５）。ここでは経路タイプが「開」であるので、ＳＩＰメッセージ中にＲＴＰプロクシ連携の処理通知があるか検査する（Ｓ３１６）。ここでは前ホップが自スコープＵＡ（ＳＩＰ ＵＡ２−１）のため、ＳＩＰメッセージにはＳＩＰプロクシの処理通知は含まれていない。ここまでがＲＴＰプロクシ連携プログラム３３４の処理条件判定部分である。ＲＴＰプロクシ連携プログラム３３４がこのような処理条件の判定を行うのは、本実施例以外のネットワーク構成も同じプログラムで対処できるようにするためである。

その後、ＲＴＰプロクシ連携プログラム３３４は、ＳＤＰの内容を解析し（Ｓ３２０）、ＲＴＰプロクシへポート割り当て要求を送る（Ｓ３２１）。ＲＴＰプロクシ５−１はポート割り当て要求に含まれるセッションの識別子（Ｓ６０５）に対して新たにポート番号を割り当て、そのポート番号を応答として返す（Ｓ６０６）。ＲＴＰプロクシ連携プログラム３３４はそのポート番号を元にＳＤＰメッセージの修正を行う（Ｓ３２２）。そして、セッション管理テーブル３３０に、該セッションにてＲＴＰプロクシ連携を実行したことを記録する（Ｓ３２３）。このような実行の記録は、これ以降、該セッションに関するＳＩＰメッセージ（２ｘｘやＡＣＫなど）を受信した際の計算を簡略化できる効果がある。

ここでは経路タイプが「開」であるため（Ｓ３２４）、ＲＴＰプロクシ連携の処理通知をＳＩＰメッセージに追加する（Ｓ３２５）。異なるスコープに属するＳＩＰプロクシに対しては、ＲＴＰプロクシ連携を実行済みであることを明示的に通知する必要がある。

この追加の例を示したものが図２０である。
図２０−ａの例では、独自に定義したＰｒｏｘｙ−Ｐｒｏｃｅｓｓｉｎｇヘッダに、ＲＴＰプロクシ連携が実行済みであることを表す「ｒｔｐ」という文字列を格納している。処理通知専用に新たなヘッダを定義しなくとも、他の意図を持って定義されたヘッダのパラメータの１つとして、このような文字列を格納してもよい。

また図２０−ｂの例では、独自に定義したＣｏｎｔｅｎｔ−Ｔｙｐｅである「ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｓｉｐ−ｐｒｏｘｙ−ｐｒｏｃｅｓｓｉｎｇ」のボディに、ＲＴＰプロクシ連携が実行済みであることを示す「ｒｔｐ」という文字列を格納している（この例では既にＳＤＰが存在するため、ボディをマルチパートにしている）。処理通知専用に新たなＣｏｎｔｅｎｔ−Ｔｙｐｅのボディを定義しなくとも、他の意図を持って定義されたＣｏｎｔｅｎｔ−Ｔｙｐｅのボディの一部として、このような文字列を格納してもよい。

また、ＲＴＰプロクシ連携を実行したことに加えて、ＲＴＰプロクシ連携に関する更に詳細な情報（ＲＴＰプロクシのドメイン名など）を上記の領域に格納してもよい。ここまでがＲＴＰプロクシ連携プログラム３３４の処理部分である。
以上の処理が終了すると、呼制御プログラム３３１はＳＩＰプロクシ３−２へとＩＮＶＩＴＥを転送する（Ｓ６０７）。

ＳＩＰプロクシ３−２がＳＩＰプロクシ３−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ６０７）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２はＳＩＰメッセージがリクエストかどうか判断し（Ｓ１０１）、リクエストの場合はそれがＡＣＫかどうか判断する（Ｓ１０２）。その後、ＳＩＰプロクシ３−１の場合とは逆に、ＳＩＰ ＵＡ２−１とＳＩＰプロクシ３−２は異なるスコープに属するため（Ｓ１０５）、経路タイプを「開」に設定する（Ｓ１０７）。ＳＩＰ ＵＡ２−２とＳＩＰプロクシ３−２は同じスコープに属するため（Ｓ１０９）、着側ＵＡの情報をロケーションサーバ４−２から取得する（Ｓ１１０）。

次に、経路決定プログラム３３２はリクエストの受信がＵＮＩ経由で行われたかＮＮＩ経由で行われたかを判別する（Ｓ１１７）。ここではＩＮＶＩＴＥの送信元のＳＩＰプロクシ３−１（他スコープＳＩＰプロクシ）を前ホップに設定する（Ｓ１２０）。

Ｓ１０８の結果から着側ＵＡが自スコープＵＡ（ＳＩＰ ＵＡ２−２）であるとわかっているため（Ｓ１２１）、経路決定プログラム３３２はＳＩＰプロクシ３−２がＳＩＰ ＵＡ２−２へＳＩＰメッセージを直接送信可能か調べる。ここでは直接送信可能なため、自スコープＵＡを次ホップに設定する（Ｓ１２３）。そして、このセッション固有の情報として、経路タイプ、前ホップ、次ホップの情報（Ｓ６１０）をセッション管理テーブルに登録する（Ｓ１２６）。そして、経路タイプなどとは別に、ロケーションサーバから取得した情報のキャッシュをセッション管理テーブルに登録する（Ｓ１２７）。経路決定プログラム３３２は以上のようにして得た情報を、呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報プログラム３３３は、ＳＩＰプロクシ３−１の場合とは逆に「着側ＵＡがＲＴＰプロクシ連携を要求する」という動的な情報を呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。呼制御プログラム３３１はＲＴＰプロクシ連携プログラム３３４のような拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。

ＲＴＰプロクシ連携プログラム３３４は、途中まではＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と同様に進むが、ここではＳＩＰプロクシ３−１によってＩＮＶＩＴＥにＲＴＰプロクシ連携の処理通知が追加されているため、Ｓ３１６にてＲＴＰプロクシ連携の処理通知ありと判断される。ＲＴＰプロクシ連携は経路上で一度だけ実行されれば十分であるため、この処理通知によって、ＳＩＰプロクシ３−２はＲＴＰプロクシ連携を行う必要がないと判断することができる。このようにして、ＳＩＰメッセージの経路上で拡張処理が余計に行われることを防ぐ。

そして、セッション管理テーブル３３０に該セッションにてＲＴＰプロクシ連携を実行しなかったことを記録し（Ｓ３１７）、プログラムを終了する。このような未実行の記録は、これ以降、該セッションに関するＳＩＰメッセージ（２ｘｘやＡＣＫなど）を受信した際の計算を簡略化できる効果がある。

以上の処理が終了すると呼制御プログラム３３１はＳＩＰ ＵＡ２−２へとＩＮＶＩＴＥを転送する（Ｓ６１１）。このとき、ＳＩＰプロクシ３−２には次ホップが自スコープＵＡであることが分かるため、ＳＩＰ ＵＡにネットワーク側での処理に関する情報が伝わらないようにしたい場合は、ＲＴＰプロクシ連携の処理通知をＩＮＶＩＴＥから削除してもよい。

ＳＩＰ ＵＡ２−２がＩＮＶＩＴＥを受信し、ここではその後にＳＤＰを含む２００（Ｓ６１２）で応答したとする。ＳＩＰプロクシ３−２はこの２００を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、ＳＩＰメッセージがレスポンスの場合はリクエスト時の情報を利用する。まず、セッション管理テーブルから該セッションのリクエスト時の経路タイプ、前ホップ、次ホップを取得する（Ｓ１１２）。そして、経路タイプをリクエスト時と同じものに設定し（Ｓ１１３）、前ホップと次ホップをリクエスト時と逆に設定して（Ｓ１１４）、得た情報（Ｓ６１３）を呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、ＳＩＰプロクシ３−２がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。ＲＴＰプロクシ連携プログラム３３４は、前ホップまたは次ホップが自スコープＵＡか検査する（Ｓ３０１）。この例では前ホップが自スコープＵＡであるため、次に発側ＵＡまたは着側ＵＡがＲＴＰプロクシ連携を要求しているか検査する（Ｓ３０２）。この例では、着側ＵＡであるＳＩＰ ＵＡ２−２がＲＴＰプロクシ連携を要求していることが分かるため、次の処理に進む。

この例では、受信したＳＩＰメッセージが２００であるため（Ｓ３０４）、セッション管理テーブル３３０から該セッションの情報を取得する（Ｓ３０６）。ここではＳＩＰメッセージはＡＣＫではなく（Ｓ３０７）、該セッションのＩＮＶＩＴＥでＳＤＰを受信しており（Ｓ３０８）、２００がＳＤＰを含んでいる（Ｓ３１３）。しかしＳＩＰプロクシ３−２はＩＮＶＩＴＥの受信時に、セッション管理テーブルにＲＴＰプロクシ連携の未実行を記録しているため（Ｓ３２６）、ＲＴＰプロクシ連携を実行せずに処理を終了する。以上の処理が終了すると呼制御プログラム３３１はＳＩＰプロクシ３−１へと２００を転送する（Ｓ６１４）。

ＳＩＰプロクシ３−１がＳＩＰプロクシ３−２からＳＤＰを含む２００（Ｓ６１４）を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。
経路決定プログラム３３２は、ＳＩＰメッセージがレスポンスの場合はリクエスト時の情報を利用する。まず、セッション管理テーブルから該セッションのリクエスト時の経路タイプ、前ホップ、次ホップを取得する（Ｓ１１２）。そして、経路タイプをリクエスト時と同じものに設定し（Ｓ１１３）、前ホップと次ホップをリクエスト時と逆に設定して（Ｓ１１４）、得た情報（Ｓ６１５）を呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、ＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。ＲＴＰプロクシ連携プログラム３３４は、途中まではＳＩＰプロクシ３−２が２００を受信した場合と同様に進むが、ＳＩＰプロクシ３−１はＩＮＶＩＴＥの受信時に、セッション管理テーブルにＲＴＰプロクシ連携の実行を記録しているため（Ｓ３２６）、処理を続行する。

ＲＴＰプロクシ連携プログラム３３４は、ＩＮＶＩＴＥを受信した際と同様に、ＳＤＰの内容を解析し（Ｓ３２７）、ＲＴＰプロクシへポート割り当て要求を送る（Ｓ３２８）。ＲＴＰプロクシ５−１はポート割り当て要求に含まれるセッションの識別子（Ｓ６１６）を見て、先ほど（Ｓ６０５、Ｓ６０６）割り当てたものと同じポート番号を応答として返す（Ｓ６１７）。ＲＴＰプロクシ連携プログラム３３４はそのポート番号を元にＳＤＰメッセージの修正を行う（Ｓ３２９）。

以上の処理が終了するとＳＩＰプロクシ３−１はＳＩＰ ＵＡ２−１へと２００を転送する（Ｓ６１８）。
以上のようにして、ＳＩＰメッセージの経路上に存在するＳＩＰプロクシの間で、ＲＴＰプロクシ連携を実行するＳＩＰプロクシを一意に決定することができる。

これによって、ＳＩＰプロクシとＲＴＰプロクシの間で交換されるメッセージ１２０が少なくなることで、ＳＩＰメッセージ転送時の遅延時間が短くなる。また、ＲＴＰストリーム１１０を中継するＲＴＰプロクシの数が減ることで、音声や動画の遅延時間が短くなる。そして、ＳＩＰメッセージとＲＴＰストリームの双方の処理量が減ることで、ＲＴＰプロクシにかかる負荷が減少するという効果がある。

実施例１では、ＳＩＰメッセージが複数のスコープを跨いだ経路を通る例を示した。そのように異なるスコープのＳＩＰプロクシ同士が連携する際には、明示的に拡張処理の処理通知を行う必要があった。

しかし、ＳＩＰメッセージが１つのスコープに閉じた経路を通る場合には、ＳＩＰプロクシ間で明示的に拡張処理の処理通知を送受信しなくとも、ＳＩＰプロクシは拡張処理が既に行われたかどうかを暗黙的に知ることが可能である。そこで本実施例では、そのような場合の動作について説明する。

図２には、本実施例で想定しているネットワークの物理的な構成図を示す。ＳＩＰ ＵＡ２−１、２−２は実施例１のものと同様である。３−１、３−２はＳＩＰプロクシであり、ロケーションサーバ４の管理する情報に基づいて、ＳＩＰメッセージの経路を決定し、転送する。通信網１、ＳＩＰ ＵＡ２−１、２−２、ＮＡＴ装置７−１、７−２、ＳＩＰプロクシ３−１、３−２、ロケーションサーバ４およびＲＴＰプロクシ５は、互いに物理的な通信回線９を介して接続されている。ＳＩＰ ＵＡ２−１、２−２はそれぞれＮＡＴ装置７−１、７−２を介して間接的に通信網１に接続されており、ＳＩＰ ＵＡ２−１、２−２はそれぞれＳＩＰプロクシ３−１、３−２を経由してのみＳＩＰメッセージを送受信できるものとする。また、これらは同じスコープ１０に所属している。

スコープ１０はロケーションサーバ４が管理する範囲というだけで、スコープの範囲は必ずしも物理的な位置によって制限されるものではない。しかし、図中では理解を助けるために、物理的な通信ネットワーク上の位置とスコープの範囲を一致させている。

実施例２及び４では、ロケーションサーバ４は各ＳＩＰ ＵＡが要求する拡張処理に関する情報として、「ＳＩＰ ＵＡ２−１がＲＴＰプロクシ連携を要求する」、「ＳＩＰ ＵＡ２−２がＲＴＰプロクシ連携を要求する」という情報を管理しているものとする。
実施例２では、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立するものとする。細い実線１００は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際のＳＩＰメッセージの流れを示したものである。ここではＳＩＰ ＵＡ２−１が発側（ＩＮＶＩＴＥを送信したＳＩＰ ＵＡ）、ＳＩＰ ＵＡ２−２が着側とする。また、破線１１０はＲＴＰストリームの流れを示したものである。
ＳＩＰプロクシ３（３−１、３−２）の内部構成と、ＳＩＰプロクシ３の各プログラムのフローチャートは、実施例１のものと同様である。

ところで、本実施例のＲＴＰプロクシ連携プログラムは「最初にＲＴＰプロクシ連携を実行できるＳＩＰプロクシが、ＲＴＰプロクシ連携を実行する」という方針に従っている。しかし、ＳＩＰメッセージが１つのスコープに閉じた経路を通る場合には、「ＲＴＰプロクシ連携を実行でき、なおかつ次ホップがＳＩＰ ＵＡの場合にＲＴＰプロクシ連携を実行する」という方針など、他の方針に従うＲＴＰプロクシ連携プログラムを作成してもよい。ただし、ＳＩＰメッセージの経路上には、一時的な障害などが原因でＲＴＰプロクシ連携を実行できないＳＩＰプロクシが存在する可能性があるため、障害対策という面では本実施例の方針に従う方が望ましい。

図１７は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際の動作の一例を示すシーケンス図である。以下では、図１７に示したシーケンス図及び図８〜１３に示したフローチャートを用いて、ＳＩＰメッセージが複数のＳＩＰプロクシを経由する際に、ＲＴＰプロクシ連携を実行するＳＩＰプロクシが動的に決定される様子を説明する。

ＳＩＰプロクシ３−１がＳＩＰ ＵＡ２−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ７０１）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２はＳＩＰメッセージがリクエストかどうか判断し（Ｓ１０１）、リクエストの場合はそれがＡＣＫかどうか判断する（Ｓ１０２）。この場合リクエストはＩＮＶＩＴＥであるため、まず経路タイプを「閉」に設定する（Ｓ１０３）。その後、発側ＵＡが自スコープＵＡか他スコープＵＡかを判別する（Ｓ１０４）。ＳＩＰ ＵＡ２−１とＳＩＰプロクシ３−１は同じスコープに属するため（Ｓ１０５）、発側ＵＡの情報をロケーションサーバ４から取得する（Ｓ１０６）。これと同様に、着側ＵＡについても自スコープＵＡか他スコープＵＡかを判別する（Ｓ１０８）。ＳＩＰ ＵＡ２−２とＳＩＰプロクシ３−１は同じスコープに属するため（Ｓ１０９）、着側ＵＡの情報をロケーションサーバ４から取得する（Ｓ１１０）。

次に、経路決定プログラム３３２はリクエストの受信がＵＮＩ経由で行われたかＮＮＩ経由で行われたかを判別する（Ｓ１１７）。この判別は、ＩＮＶＩＴＥの送信元アドレスが、ＮＮＩとして事前に登録されているものかどうか比較するなどして行う。ＩＮＶＩＴＥの送信元アドレスはＳＩＰ ＵＡ２−１であるため、発側ＵＡ（自スコープＵＡ）を前ホップに設定する（Ｓ１１９）。

Ｓ１１０でロケーションサーバ４から取得した情報によって、ＳＩＰプロクシ３−１は着側ＵＡと同じスコープに属しているが（Ｓ１２１）、直接ＳＩＰメッセージを転送できないことが分かる（Ｓ１２２）。そのため、経路決定プログラム３３２はＳＩＰ ＵＡ２−２へとＩＮＶＩＴＥを転送できるＳＩＰプロクシ３−２（自スコープＳＩＰプロクシ）を次ホップに設定する（Ｓ１２４）。そして、このセッション固有の情報として、経路タイプ、前ホップ、次ホップの情報（Ｓ７０４）をセッション管理テーブルに登録する（Ｓ１２６）。そして、経路タイプなどとは別に、ロケーションサーバから取得した情報のキャッシュをセッション管理テーブルに登録する（Ｓ１２７）。経路決定プログラム３３２は以上のようにして得た情報を、呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。
処理情報取得プログラム３３３は、自スコープに属するＳＩＰ ＵＡの情報のキャッシュをセッション管理テーブルから取得する（これはＳ１２７で登録されたものである）。本実施例ではキャッシュを利用しているが、キャッシュを利用しない場合はここで再びロケーションサーバにアクセスしてもよい。また、拡張処理に関する動的な情報を格納する専用のサーバがロケーションサーバ以外に存在する場合はそのサーバにアクセスしてもよい。スループットを重視する場合はキャッシュを利用し、ＳＩＰプロクシ上のメモリやディスク領域の節約を重視する場合はロケーションサーバや専用のサーバを利用することが望ましい。

この例では発側ＵＡも着側ＵＡが自スコープＵＡであるため（Ｓ２０１、Ｓ２０３）、それぞれの処理情報を取得する（Ｓ２０２、Ｓ２０４）。その後、自スコープ内で共通の処理情報を静的処理情報テーブルから取得する（Ｓ２０５）。実施例２では、静的処理情報テーブル３３７は何の情報も含まないため、静的な情報は何も取得できない。処理情報取得プログラム３３３は以上のようにして得た「発側ＵＡと着側ＵＡがＲＴＰプロクシ連携を要求する」という動的な情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。呼制御プログラム３３１はＲＴＰプロクシ連携プログラム３３４のような拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。

ＲＴＰプロクシ連携プログラム３３４は、Ｓ３１５までは、実施例１にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と同様に進む。しかし、実施例２では経路タイプが「閉」であるので、次に前ホップが自スコープＳＩＰプロクシかどうかを検査する（Ｓ３１８）。ここでは前ホップが自スコープＵＡ（ＳＩＰ ＵＡ２−１）のため、プログラムを続行する。ここまでがＲＴＰプロクシ連携プログラム３３４の処理条件判定部分である。ＲＴＰプロクシ連携プログラム３３４がこのような処理条件の判定を行うのは、本実施例以外のネットワーク構成も同じプログラムで対処できるようにするためである。

その後、ＲＴＰプロクシ連携プログラム３３４は、ＳＤＰの内容を解析し（Ｓ３２０）、ＲＴＰプロクシへポート割り当て要求を送る（Ｓ３２１）。ＲＴＰプロクシ５−１はポート割り当て要求に含まれるセッションの識別子（Ｓ７０５）に対して新たにポート番号を割り当て、そのポート番号を応答として返す（Ｓ７０６）。ＲＴＰプロクシ連携プログラム３３４はそのポート番号を元にＳＤＰメッセージの修正を行う（Ｓ３２２）。そして、セッション管理テーブル３３０に、該セッションにてＲＴＰプロクシ連携を実行したことを記録する（Ｓ３２３）。このような実行の記録は、これ以降、該セッションに関するＳＩＰメッセージ（２ｘｘやＡＣＫなど）を受信した際の計算を簡略化できる効果がある。

ここでは経路タイプが「閉」であるため（Ｓ３２４）、ＲＴＰプロクシ連携の処理通知をＳＩＰメッセージに追加する必要はない。ただし、ＳＩＰプロクシ同士の連携をより厳密に行いたい場合は、経路タイプが「閉」の場合も、実施例１と同様にＲＴＰプロクシ連携の処理通知をＳＩＰメッセージに追加してもよい。ここまでがＲＴＰプロクシ連携プログラム３３４の処理部分である。

以上の処理が終了すると、呼制御プログラム３３１はＳＩＰプロクシ３−２へとＩＮＶＩＴＥを転送する（Ｓ７０７）。
ＳＩＰプロクシ３−２がＳＩＰプロクシ３−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ７０７）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、Ｓ１１８までは、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と同様に進む。しかし、ＳＩＰプロクシ３−２はＳＩＰプロクシ３−１からＩＮＶＩＴＥを受信するため、ここではＩＮＶＩＴＥの送信元のＳＩＰプロクシ３−１（自スコープＳＩＰプロクシ）を前ホップに設定する（Ｓ１２０）。

Ｓ１０８の結果から着側ＵＡが自スコープＵＡ（ＳＩＰ ＵＡ２−２）であるとわかっているため（Ｓ１２１）、経路決定プログラム３３２はＳＩＰプロクシ３−２がＳＩＰ ＵＡ２−２へＳＩＰメッセージを直接送信可能か調べる。Ｓ１１０でロケーションサーバ４から取得した情報によって、ＳＩＰプロクシ３−２はＳＩＰ ＵＡ２−２へ直接ＳＩＰメッセージを転送できることが分かるため、ＳＩＰ ＵＡ２−２（自スコープＵＡ）を次ホップに設定する（Ｓ１２３）。そして、このセッション固有の情報として、経路タイプ、前ホップ、次ホップの情報（Ｓ７１０）をセッション管理テーブルに登録する（Ｓ１２６）。そして、経路タイプなどとは別に、ロケーションサーバから取得した情報のキャッシュをセッション管理テーブルに登録する（Ｓ１２７）。経路決定プログラム３３２は以上のようにして得た情報を、呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報プログラム３３３は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同様に進み、「発側ＵＡと着側ＵＡがＲＴＰプロクシ連携を要求する」という動的な情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。呼制御プログラム３３１はＲＴＰプロクシ連携プログラム３３４のような拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。

ＲＴＰプロクシ連携プログラム３３４は、途中までは本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と同様に進む。しかし、経路タイプが「閉」で（Ｓ３１５）、前ホップが自スコープＳＩＰプロクシの場合には（Ｓ３１８）、前ホップのＳＩＰプロクシがＲＴＰプロクシ連携を既に実行していることが暗黙的に分かる。ＲＴＰプロクシ連携は経路上で一度だけ実行されれば十分であるため、ＳＩＰプロクシ３−２はＲＴＰプロクシ連携を行う必要がないと判断することができる。このようにして、ＳＩＰメッセージが１つのスコープに閉じた経路を通る場合にも、ＳＩＰメッセージの経路上で拡張処理が余計に行われることを防ぐ。そして、セッション管理テーブル３３０に該セッションにてＲＴＰプロクシ連携を実行しなかったことを記録し（Ｓ３１９）、プログラムを終了する。

ただし、ＳＩＰプロクシ同士の連携をより厳密に行いたい場合には、経路タイプが「閉」の場合も、ＲＴＰプロクシ連携の処理通知がない場合はＲＴＰプロクシ連携を実行するようにしてもよい。

以上の処理が終了すると呼制御プログラム３３１はＳＩＰ ＵＡ２−２へとＩＮＶＩＴＥを転送する（Ｓ７１１）。このとき、ＳＩＰプロクシ３−２には次ホップが自スコープＵＡであることが分かるため、ＳＩＰ ＵＡにネットワーク側での処理に関する情報が伝わらないように、ＲＴＰプロクシ連携の処理通知をＩＮＶＩＴＥから削除してもよい。

ＳＩＰ ＵＡ２−２がＩＮＶＩＴＥを受信し、ここではその後ＳＤＰを含む２００（Ｓ７１２）で応答したとする。ＳＩＰプロクシ３−２はこの２００を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、ＳＩＰメッセージがレスポンスの場合はリクエスト時の情報を利用する。まず、セッション管理テーブルから該セッションのリクエスト時の経路タイプ、前ホップ、次ホップを取得する（Ｓ１１２）。そして、経路タイプをリクエスト時と同じものに設定し（Ｓ１１３）、前ホップと次ホップをリクエスト時と逆に設定して（Ｓ１１４）、得た情報（Ｓ７１３）を呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、本実施例にてＳＩＰプロクシ３−２がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。しかしＳＩＰプロクシ３−２はＩＮＶＩＴＥの受信時に、セッション管理テーブルにＲＴＰプロクシ連携の未実行を記録しているため、ＲＴＰプロクシ連携を実行せずに処理を終了する（Ｓ３２６）。以上の処理が終了すると呼制御プログラム３３１はＳＩＰプロクシ３−１へと２００を転送する（Ｓ７１４）。

ＳＩＰプロクシ３−１がＳＩＰプロクシ３−２からＳＤＰを含む２００（Ｓ７１４）を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。
経路決定プログラム３３２は、ＳＩＰメッセージがレスポンスの場合はリクエスト時の情報を利用する。まず、セッション管理テーブルから該セッションのリクエスト時の経路タイプ、前ホップ、次ホップを取得する（Ｓ１１２）。そして、経路タイプをリクエスト時と同じものに設定し（Ｓ１１３）、前ホップと次ホップをリクエスト時と逆に設定して（Ｓ１１４）、得た情報（Ｓ７１５）を呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報プログラム３３３は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。
ＳＩＰプロクシ３−１はＩＮＶＩＴＥの受信時に、セッション管理テーブルにＲＴＰプロクシ連携の実行を記録しているため（Ｓ３２６）、処理を続行する。

ＲＴＰプロクシ連携プログラム３３４は、ＩＮＶＩＴＥを受信した際と同様に、ＳＤＰの内容を解析し（Ｓ３２７）、ＲＴＰプロクシへポート割り当て要求を送る（Ｓ３２８）。ＲＴＰプロクシ５−１はポート割り当て要求に含まれるセッションの識別子（Ｓ７１６）を見て、先ほど（Ｓ７０５、Ｓ７０６）割り当てたものと同じポート番号を応答として返す（Ｓ７１７）。ＲＴＰプロクシ連携プログラム３３４はそのポート番号を元にＳＤＰメッセージの修正を行う（Ｓ３２９）。

以上の処理が終了するとＳＩＰプロクシ３−１はＳＩＰ ＵＡ２−１へと２００を転送する（Ｓ７１８）。
以上のようにして、ＳＩＰメッセージが１つのスコープに閉じた経路を通る場合には、拡張処理の処理通知を行わなくとも、ＲＴＰプロクシ連携を実行するＳＩＰプロクシを一意に決定することができる。

これによって、ＳＩＰプロクシとＲＴＰプロクシの間で交換されるメッセージ１２０が少なくなることで、ＳＩＰメッセージ転送時の遅延時間が短くなる。また、ＲＴＰストリーム１１０を中継するＲＴＰプロクシの数が減ることで、音声や動画の遅延時間が短くなる。そして、ＳＩＰメッセージとＲＴＰストリームの双方の処理量が減ることで、ＲＴＰプロクシにかかる負荷が減少するという効果がある。

また、実施例１とは異なり、本実施例のように単一のスコープ内で冗長構成をとる場合には、元となる呼制御プロトコル（この場合はＳＩＰ）への拡張を必要としない。
１つのスコープの中にはＲＴＰプロクシが１つしかないことも考えられるが、その場合もＳＩＰプロクシとＲＴＰプロクシの間で交換されるメッセージ１２０を削減できる、という効果がある。

実施例１と２では、ＳＩＰプロクシが拡張処理の一種であるＲＴＰプロクシ連携を実行する例を示した。本実施例では、拡張処理の異なる例として、ＳＩＰプロクシ−プレゼンスサーバ間連携（以下、プレゼンスサーバ連携）を行う場合の動作について説明する。本実施例でプレゼンスサーバ連携と呼ぶものは、ＳＩＰ ＵＡ間でセッションが確立されるとＳＩＰプロクシが双方のＳＩＰ ＵＡの状態を「通話中」に更新し、セッションか終了すると「通話可能」に更新するものであるとする。
また、本実施例及び実施例４では、ロケーションサーバのスコープと、プレゼンスサーバが管理するＳＩＰ ＵＡとＳＩＰプロクシの範囲は一致することを前提とする。

図３には、本実施例で想定しているネットワークの物理的な構成図を示す。ＳＩＰ ＵＡ２−１、２−２は実施例１のものと同様である。３−１、３−２はＳＩＰプロクシであり、ロケーションサーバ４の管理する情報に基づいて、ＳＩＰメッセージの経路を決定し、転送する。通信網１、ＳＩＰ ＵＡ２−１、２−２、ＳＩＰプロクシ３−１、３−２、ロケーションサーバ４およびプレゼンスサーバ６は、互いに物理的な通信回線９を介して接続されている。ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）等のセキュリティ接続を維持しているという理由により、ＳＩＰ ＵＡ２−１、２−２はそれぞれＳＩＰプロクシ３−１、３−２を経由してのみＳＩＰメッセージを送受信できるものとする。しかし、本実施例はこの理由に限定されるものではなく、ＳＩＰメッセージが同様の経路を辿る場合には同様の処理が行われる。

また、これらは同じスコープ１０に所属している。スコープ１０はロケーションサーバ４が管理する範囲というだけで、スコープの範囲は必ずしも物理的な位置によって制限されるものではない。しかし、図中では理解を助けるために、物理的な通信ネットワーク上の位置とスコープの範囲を一致させている。

実施例３では、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立するものとする。細い実線１００は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際のＳＩＰメッセージの流れを示したものである。ここではＳＩＰ ＵＡ２−１が発側（ＩＮＶＩＴＥを送信したＳＩＰ ＵＡ）、ＳＩＰ ＵＡ２−２が着側とする。

図６には、図３に示したＳＩＰプロクシ３（ＳＩＰプロクシ３−１、ＳＩＰプロクシ３−２共通）の内部構成を機能展開して示したブロック図を示す。ＲＴＰプロクシ連携プログラム３３４の代わりにプレゼンスサーバ連携プログラム３３５がメモリ３３に格納されている点以外は、実施例１のＳＩＰプロクシ３の内部構成（図５）と同じである。
また、プレゼンスサーバ連携プログラム３３５以外の各プログラムのフローチャートは、実施例１と同様である。

プレゼンスサーバ連携プログラム３３５は拡張処理を行うプログラムの一種で、経路決定プログラム３３２と処理情報取得プログラム３３３の計算結果を受け取り、特定の条件を満たす場合のみプレゼンスサーバ連携を実行する。本実施例及び実施例４では、ＳＩＰプロクシ３からプレゼンスサーバ６に対してＳＩＰメッセージのＰＵＢＬＩＳＨを送信することでＳＩＰ ＵＡの状態を更新するものとする。ただし、ＳＩＰ ＵＡの状態を更新する方法はＰＵＢＬＩＳＨに限定されない。

ところで、本実施例及び実施例４のプレゼンスサーバ連携プログラム３３５は「最初にプレゼンスサーバ連携を実行できるＳＩＰプロクシが、プレゼンスサーバ連携を実行する」という方針に従っている。しかし、ＳＩＰメッセージが１つのスコープに閉じた経路を通る場合には、「プレゼンスサーバ連携を実行でき、なおかつ次ホップがＳＩＰ ＵＡの場合にプレゼンスサーバ連携を実行する」という方針など、他の方針に従うプレゼンスサーバ連携プログラムを作成してもよい。ただし、ＳＩＰメッセージの経路上には、一時的な障害などが原因でプレゼンスサーバ連携を実行できないＳＩＰプロクシが存在する可能性があるため、障害対策という面では本実施例及び実施例４の方針に従う方が望ましい。

また、本実施例及び実施例４では、静的処理情報テーブル３３７に「全ての自スコープＵＡはプレゼンスサーバ連携を要求する」という情報を格納しているものとする。一部のＵＡのみがプレゼンスサーバ連携を要求する場合は、静的処理情報テーブル３３７にそのような情報を格納する必要があるが、その場合も本実施例と同じプレゼンスサーバ連携プログラム３３５で対処できる。

図１８は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際の動作の一例を示すシーケンス図である。以下では、図１８に示したシーケンス図及び図８〜１０、図１４〜１５に示したフローチャートを用いて、ＳＩＰメッセージが複数のＳＩＰプロクシを経由する際に、プレゼンスサーバ連携を実行するＳＩＰプロクシが動的に決定される様子を説明する。

ＳＩＰプロクシ３−１がＳＩＰ ＵＡ２−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ８０１）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、実施例２におけるＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と全く同じように動作する。そして、そのようにして得た情報（Ｓ８０４）を、呼制御プログラム３３１に返す。
経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。

処理情報取得プログラム３３３は、自スコープに属するＳＩＰ ＵＡの情報のキャッシュをセッション管理テーブルから取得する（これはＳ１２７で登録されたものである）。本実施例ではキャッシュを利用しているが、キャッシュを利用しない場合はここで再びロケーションサーバにアクセスしてもよい。また、拡張処理に関する動的な情報を格納する専用のサーバがロケーションサーバ以外に存在する場合はそのサーバにアクセスしてもよい。スループットを重視する場合はキャッシュを利用し、ＳＩＰプロクシ上のメモリやディスク領域の節約を重視する場合はロケーションサーバや専用のサーバを利用することが望ましい。

この例では発側ＵＡも着側ＵＡが自スコープＵＡであるため（Ｓ２０１、Ｓ２０３）、それぞれの処理情報を取得する（Ｓ２０２、Ｓ２０４）。本実施例では動的な情報に基づく拡張処理（ＲＴＰプロクシ連携など）が存在しないため、動的な情報は何も取得できない。その後、自スコープ内で共通の処理情報を静的処理情報テーブルから取得する（Ｓ２０５）。処理情報取得プログラム３３３は以上のようにして得た「全ての自スコープＵＡはプレゼンスサーバ連携を要求する」という静的な情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、プレゼンスサーバ連携プログラム３３５を呼び出す。呼制御プログラム３３１はプレゼンスサーバ連携プログラム３３５のような拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。

プレゼンスサーバ連携プログラム３３５は、前ホップまたは次ホップが自スコープＵＡか検査する（Ｓ４０１）。この例では両者とも自スコープＵＡであるため、次に静的処理情報がプレゼンスサーバ連携を要求しているか検査する（Ｓ４０２）。この例では、Ｓ２０５にて静的処理情報テーブル３３７から取得した情報により、自ドメインＵＡである発側ＵＡと着側ＵＡがプレゼンスサーバ連携を要求していることが分かるため、次の処理に進む。

しかし、この例ではＳＩＰメッセージがＩＮＶＩＴＥであるため、Ｓ４０３とＳ４１３の検査の後に処理を終了する。セッションの確立中から実行されるＲＴＰプロクシ連携とは異なり、プレゼンスサーバ連携はセッションの確立後に実行される。
以上の処理が終了すると、呼制御プログラム３３１はＳＩＰプロクシ３−２へとＩＮＶＩＴＥを転送する（Ｓ８０５）。

ＳＩＰプロクシ３−２がＳＩＰプロクシ３−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ８０５）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。
経路決定プログラム３３２は、実施例２におけるＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と全く同じように動作する。そして、そのようにして得た情報（Ｓ８０８）を、呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報プログラム３３３は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同様に進み、「全ての自スコープＵＡはプレゼンスサーバ連携を要求する」という情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、プレゼンスサーバ連携プログラム３３５を呼び出す。呼制御プログラム３３１はプレゼンスサーバ連携プログラム３３５のような拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。
プレゼンスサーバ連携プログラム３３５は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同様に進み、プレゼンスサーバ連携を行う前に処理を終了する。
以上の処理が終了すると呼制御プログラム３３１はＳＩＰ ＵＡ２−２へとＩＮＶＩＴＥを転送する（Ｓ８０９）。

ＳＩＰ ＵＡ２−２がＩＮＶＩＴＥを受信し、ここではその後ＳＤＰを含む２００（Ｓ８１０）で応答したとする。ＳＩＰプロクシ３−２はこの２００を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、ＳＩＰメッセージがレスポンスの場合はリクエスト時の情報を利用する。まず、セッション管理テーブルから該セッションのリクエスト時の経路タイプ、前ホップ、次ホップを取得する（Ｓ１１２）。そして、経路タイプをリクエスト時と同じものに設定し（Ｓ１１３）、前ホップと次ホップをリクエスト時と逆に設定して（Ｓ１１４）、得た情報（Ｓ８１１）を呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、本実施例にてＳＩＰプロクシ３−２がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。
そして呼制御プログラム３３１は、プレゼンスサーバ連携プログラム３３５を呼び出す。

プレゼンスサーバ連携プログラム３３５は、前ホップまたは次ホップが自スコープＵＡか検査する（Ｓ４０１）。この例では両者とも自スコープＵＡであるため、次に静的処理情報がプレゼンスサーバ連携を要求しているか検査する（Ｓ４０２）。この例では、Ｓ２０５にて静的処理情報テーブル３３７から取得した情報により、自スコープＵＡである発側ＵＡと着側ＵＡがプレゼンスサーバ連携を要求していることが分かるため、次の処理に進む。

この例では、受信したＳＩＰメッセージが２００であるため（Ｓ４０３）、セッション管理テーブルから該セッションの情報を取得する。そして、受信したＳＩＰメッセージが２００であり（Ｓ４０５）、該セッションのＩＮＶＩＴＥがＳＤＰを含んでおり（Ｓ４０６）、ＳＩＰメッセージ（ここで言う２００）もＳＤＰを含んでいる（Ｓ４０７）。そのため、次に経路タイプが「閉」かどうかを検査する（Ｓ４１４）。ここでは経路タイプが「閉」であるが、前ホップが自スコープＵＡ（ＳＩＰ ＵＡ２−２）であるため（Ｓ４１５）、処理を続行する。ここまでがプレゼンスサーバ連携プログラム３３５の処理条件判定部分である。プレゼンスサーバ連携プログラム３３５がこのような処理条件の判定を行うのは、本実施例以外のネットワーク構成も同じプログラムで対処できるようにするためである。

その後、プレゼンスサーバ連携プログラム３３５は、発側ＵＡと着側ＵＡが自スコープＵＡかどうかをそれぞれ判定し（Ｓ４１６、Ｓ４２０）、共に自スコープＵＡなので状態を「通話中」に更新する（Ｓ４１８、Ｓ４２２）。ＲＴＰプロクシ連携とは異なり、プレゼンスサーバ連携は一度の処理で終了するため、セッション管理テーブルにプレゼンスサーバ連携の実行を記録する必要はない。

本実施例及び実施例４では、ロケーションサーバ４のスコープと、プレゼンスサーバが管理するＳＩＰ ＵＡとＳＩＰプロクシの範囲は一致するという前提条件がある。つまりスコープ毎に１回プレゼンスサーバ連携を行うため、異なるスコープに属するＳＩＰプロクシ間でプレゼンスサーバ連携の処理通知を送受信する必要はない。ただし、ＳＩＰプロクシ同士の連携をより厳密に行いたい場合は、経路タイプが「閉」の場合のみ、ＲＴＰプロクシ連携の処理通知と同様の方法で、プレゼンスサーバ連携の処理通知をＳＩＰメッセージに追加してもよい。ここまでがプレゼンスサーバ連携プログラム３３５の処理部分である。

以上の処理が終了すると呼制御プログラム３３１はＳＩＰプロクシ３−１へと２００を転送する（Ｓ８１４）。
ＳＩＰプロクシ３−１がＳＩＰプロクシ３−２からＳＤＰを含む２００（Ｓ８１４）を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、ＳＩＰメッセージがレスポンスの場合はリクエスト時の情報を利用する。まず、セッション管理テーブルから該セッションのリクエスト時の経路タイプ、前ホップ、次ホップを取得する（Ｓ１１２）。そして、経路タイプをリクエスト時と同じものに設定し（Ｓ１１３）、前ホップと次ホップをリクエスト時と逆に設定して（Ｓ１１４）、得た情報（Ｓ８１５）を呼制御プログラム３３１に返す。

経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４を呼び出す。
ＲＴＰプロクシ連携プログラム３３４は、途中まではＳＩＰプロクシ３−２が２００を受信した場合と同様に進むが、経路タイプが「閉」で（Ｓ４１４）、前ホップが自スコープＳＩＰプロクシの場合には（Ｓ４１５）、前ホップのＳＩＰプロクシがプレゼンスサーバ連携を既に実行していることが暗黙的に分かるため、プログラムを終了する。

ただし、ＳＩＰプロクシ同士の連携をより厳密に行いたい場合には、経路タイプが「閉」の場合に、プレゼンスサーバ連携の処理通知がない場合はプレゼンスサーバ連携を実行するようにしてもよい。
以上の処理が終了すると呼制御プログラム３３１はＳＩＰ ＵＡ２−１へとＩＮＶＩＴＥを転送する（Ｓ８１６）。
以上のようにして、ＲＴＰプロクシ連携以外の拡張処理であるプレゼンスサーバ連携についても、処理条件判定部分と処理部分からなるプログラムを追加することで、その拡張処理を実行するＳＩＰプロクシを一意に決定することができる。

これによって、ＳＩＰプロクシとプレゼンスサーバの間で交換されるメッセージ１３０が少なくなることで、ＳＩＰメッセージ転送時の遅延時間が短くなる。また、ＳＩＰメッセージの処理量が減ることで、プレゼンスサーバにかかる負荷が減少するという効果がある。
また、実施例１とは異なり、本実施例のように単一のスコープ内で冗長構成をとる限りにおいては、元となる呼制御プロトコル（この場合はＳＩＰ）への拡張を必要としない。

実施例１〜３では、ＳＩＰプロクシが単一の拡張処理を実行する例を示した。本実施例では、ＳＩＰプロクシが複数の拡張処理を実行する場合の動作について説明する。本実施例では、実施例１と２で示したＲＴＰプロクシ連携と、実施例３で示したプレゼンスサーバ連携という、２つの拡張処理を実行するものとする。

図４には、本実施例で想定しているネットワークの物理的な構成図を示す。ＲＴＰプロクシ５に加えてプレゼンスサーバ６が物理的な通信回線９を介して通信網１に接続されている点以外は、実施例２の構成図（図２）と同じである。

図７には、図４に示したＳＩＰプロクシ３（ＳＩＰプロクシ３−１、ＳＩＰプロクシ３−２共通）の内部構成を機能展開して示したブロック図を示す。ＲＴＰプロクシ連携プログラム３３４に加えてプレゼンスサーバ連携プログラム３３５がメモリ３３に格納されている点以外は、実施例１のＳＩＰプロクシ３の内部構成（図５）と同じである。

また、プレゼンスサーバ連携プログラム３３５以外の各プログラムのフローチャートは実施例１と同様であり、プレゼンスサーバ連携プログラム３３５のフローチャートは実施例３と同様である。静的処理情報テーブル３３７には実施例３と同様の情報を格納しているものとする。

図１９は、ＳＩＰ ＵＡ２−１とＳＩＰ ＵＡ２−２の間でセッションを確立する際の動作の一例を示すシーケンス図である。以下では、図１９に示したシーケンス図及び図８〜１５に示したフローチャートを用いて、ＳＩＰメッセージが複数のＳＩＰプロクシを経由する際に、ＲＴＰプロクシ連携とプレゼンスサーバ連携を実行するＳＩＰプロクシがそれぞれ動的に決定される様子を説明する。

ＳＩＰプロクシ３−１がＳＩＰ ＵＡ２−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ９０１）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、実施例２におけるＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と全く同じように動作する。そして、そのようにして得た情報（Ｓ９０４）を、呼制御プログラム３３１に返す。
経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。

処理情報取得プログラム３３３は、自スコープに属するＳＩＰ ＵＡの情報のキャッシュをセッション管理テーブルから取得する（これはＳ１２７で登録されたものである）。本実施例ではキャッシュを利用しているが、キャッシュを利用しない場合はここで再びロケーションサーバにアクセスしてもよい。また、拡張処理に関する動的な情報を格納する専用のサーバがロケーションサーバ以外に存在する場合はそのサーバにアクセスしてもよい。スループットを重視する場合はキャッシュを利用し、ＳＩＰプロクシ上のメモリやディスク領域の節約を重視する場合はロケーションサーバや専用のサーバを利用することが望ましい。

この例では発側ＵＡも着側ＵＡが自スコープＵＡであるため（Ｓ２０１、Ｓ２０３）、それぞれの処理情報を取得する（Ｓ２０２、Ｓ２０４）。その後、自スコープ内で共通の処理情報を静的処理情報テーブルから取得する（Ｓ２０５）。処理情報取得プログラム３３３は以上のようにして得た「発側ＵＡと着側ＵＡがＲＴＰプロクシ連携を要求する」という動的な情報と「全ての自スコープＵＡはプレゼンスサーバ連携を要求する」という静的な情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４と、プレゼンスサーバ連携プログラム３３５を呼び出す。呼制御プログラム３３１はこれらの拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。これらの拡張処理プログラムを呼び出す順番を変更しても、全体の処理結果が変わることはない。

ＲＴＰプロクシ連携プログラム３３４は、実施例２におけるＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と全く同じように動作し、ＲＴＰプロクシ連携を実行する。そして、セッション管理テーブル３３０に、該セッションにてＲＴＰプロクシ連携を実行したことを記録して（Ｓ３２３）、プログラムを終了する。

プレゼンスサーバ連携プログラム３３５は、実施例３におけるＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と全く同じように動作し、プレゼンスサーバ連携を実行せずにプログラムを終了する。
以上の処理が終了すると、呼制御プログラム３３１はＳＩＰプロクシ３−２へとＩＮＶＩＴＥを転送する（Ｓ９０７）。

ＳＩＰプロクシ３−２がＳＩＰプロクシ３−１からＳＤＰを含むＩＮＶＩＴＥ（Ｓ９０７）を受信すると、そのＩＮＶＩＴＥはまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、実施例２におけるＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した場合と全く同じように動作する。そして、そのようにして得た情報（Ｓ９１０）を、呼制御プログラム３３１に返す。
経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。

処理情報プログラム３３３は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同様に進み、「発側ＵＡと着側ＵＡがＲＴＰプロクシ連携を要求する」という動的な情報と「全ての自スコープＵＡはプレゼンスサーバ連携を要求する」という静的な情報を、呼制御プログラム３３１に返す。

そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４と、プレゼンスサーバ連携プログラム３３５を呼び出す。呼制御プログラム３３１はこれらの拡張処理プログラムを呼び出す際に、経路決定プログラム３３２と処理情報取得プログラム３３３から受け取った計算結果を渡す。これらの拡張処理プログラムを呼び出す順番を変更しても、全体の処理結果が変わることはない。

ＲＴＰプロクシ連携プログラム３３４は、実施例２におけるＳＩＰプロクシ３−２がＩＮＶＩＴＥを受信した場合と全く同じように動作し、ＲＴＰプロクシ連携を実行しない。そして、セッション管理テーブル３３０に、該セッションにてＲＴＰプロクシ連携を実行しなかったことを記録して（Ｓ３１９）、プログラムを終了する。

プレゼンスサーバ連携プログラム３３５は、実施例３におけるＳＩＰプロクシ３−２がＩＮＶＩＴＥを受信した場合と全く同じように動作し、プレゼンスサーバ連携を実行せずにプログラムを終了する。
以上の処理が終了すると呼制御プログラム３３１はＳＩＰ ＵＡ２−２へとＩＮＶＩＴＥを転送する（Ｓ９１１）。

ＳＩＰ ＵＡ２−２がＩＮＶＩＴＥを受信し、ここではその後ＳＤＰを含む２００（Ｓ９１２）で応答したとする。ＳＩＰプロクシ３−２はこの２００を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、実施例２におけるＳＩＰプロクシ３−２が２００を受信した場合と全く同じように動作する。そして、そのようにして得た情報（Ｓ９１３）を、呼制御プログラム３３１に返す。
経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、本実施例にてＳＩＰプロクシ３−２がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。 そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４と、プレゼンスサーバ連携プログラム３３５を呼び出す。
ＲＴＰプロクシ連携プログラム３３４は、実施例２におけるＳＩＰプロクシ３−２が２００を受信した場合と全く同じように動作し、ＲＴＰプロクシ連携を実行せずにプログラムを終了する。

プレゼンスサーバ連携プログラム３３５は、実施例３におけるＳＩＰプロクシ３−２が２００を受信した場合と全く同じように動作し、プレゼンスサーバ連携を実行する。そしてプログラムを終了する。
以上の処理が終了すると呼制御プログラム３３１はＳＩＰプロクシ３−１へと２００を転送する（Ｓ９１６）。

ＳＩＰプロクシ３−１がＳＩＰプロクシ３−２からＳＤＰを含む２００（Ｓ９１６）を受信すると、その２００はまず呼制御プログラム３３１に渡される。そして、呼制御プログラム３３１はその処理の中で経路決定プログラム３３２を呼び出す。

経路決定プログラム３３２は、実施例２におけるＳＩＰプロクシ３−１が２００を受信した場合と全く同じように動作する。そして、そのようにして得た情報（Ｓ９１７）を、呼制御プログラム３３１に返す。
経路決定プログラム３３２が終了すると、呼制御プログラム３３１は次に処理情報取得プログラム３３３を呼び出す。処理情報取得プログラム３３３は、本実施例にてＳＩＰプロクシ３−１がＩＮＶＩＴＥを受信した際と同じ情報を呼制御プログラム３３１に返す。
そして呼制御プログラム３３１は、ＲＴＰプロクシ連携プログラム３３４と、プレゼンスサーバ連携プログラム３３５を呼び出す。

ＲＴＰプロクシ連携プログラム３３４は、実施例２におけるＳＩＰプロクシ３−１が２００を受信した場合と全く同じように動作し、ＲＴＰプロクシ連携を実行する。そしてプログラムを終了する。
プレゼンスサーバ連携プログラム３３５は、実施例３におけるＳＩＰプロクシ３−１が２００を受信した場合と全く同じように動作し、プレゼンスサーバ連携を実行せずにプログラムを終了する。
以上の処理が終了すると呼制御プログラム３３１はＳＩＰ ＵＡ２−１へとＩＮＶＩＴＥを転送する（Ｓ９２０）。
以上のようにして、ＳＩＰプロクシの実行する拡張処理が複数ある場合についても、そのそれぞれの拡張処理を実行するＳＩＰプロクシを一意に決定することができる。また、処理条件の判定はそれぞれの拡張処理毎に行われるため、１つのＳＩＰプロクシが必ずしも全ての拡張処理を実行するわけではないことを示した。

これによって、ＳＩＰプロクシと外部サーバ（ＲＴＰプロクシ、プレゼンスサーバ）の間で交換されるメッセージが少なくなることで、ＳＩＰメッセージ転送時の遅延時間が短くなる。ＳＩＰプロクシから送信されるメッセージの処理量が減ることで、外部サーバにかかる負荷が減少するという効果もある。

また、実施例１とは異なり、本実施例のように単一のスコープ内で冗長構成をとる限りにおいては、元となる呼制御プロトコル（この場合はＳＩＰ）への拡張を必要としない。
そして、経路決定プログラム３３２と処理情報取得プログラム３３３の計算結果を、それぞれの拡張処理プログラムに渡す仕組みになっているため、ＳＩＰプロクシの基本的なプログラム（呼制御プログラム３３１、経路決定プログラム３３２、処理情報取得プログラム３３３）に変更を加えることなく、実施例４で示したもの以外の拡張処理プログラムも新たに追加することができる。ＲＴＰプロクシ連携とプレゼンスサーバ連携以外に考えられる拡張処理プログラムとしては、Ｗｅｂサーバとの連携、ログの記録、課金情報の記録、ＱｏＳ制御などがある。

以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。また、本発明の効果を奏する限り、プロトコルはＳＩＰに限定されない。

実施例１で想定するネットワークの物理的な構成を示す図である。 実施例２で想定するネットワークの物理的な構成を示す図である。 実施例３で想定するネットワークの物理的な構成を示す図である。 実施例４で想定するネットワークの物理的な構成を示す図である。 実施例１、２のＳＩＰプロクシの内部構成を機能展開して示した図である。 実施例３のＳＩＰプロクシの内部構成を機能展開して示した図である。 実施例４のＳＩＰプロクシの内部構成を機能展開して示した図である。 経路決定プログラムの内部動作を示すフローチャートである。 経路決定プログラムの内部動作を示すフローチャートである。 処理情報取得プログラムの内部動作を示すフローチャートである。 ＲＴＰプロクシ連携プログラムの内部動作を示すフローチャートである。 ＲＴＰプロクシ連携プログラムの内部動作を示すフローチャートである。 ＲＴＰプロクシ連携プログラムの内部動作を示すフローチャートである。 プレゼンスサーバ連携プログラムの内部動作を示すフローチャートである。 プレゼンスサーバ連携プログラムの内部動作を示すフローチャートである。 実施例１の動作シーケンスを示す図である。 実施例２の動作シーケンスを示す図である。 実施例３の動作シーケンスを示す図である。 実施例４の動作シーケンスを示す図である。 実施例１にて、ＲＴＰプロクシ連携の処理通知が追加されたＳＩＰメッセージの例を示す図である。 従来のＳＩＰプロクシを用いたネットワークの物理的な構成を示す図である。

符号の説明

１ 通信網
２ ＳＩＰ ＵＡ
３ ＳＩＰプロクシ
４ ロケーションサーバ
５ ＲＴＰプロクシ
６ プレゼンスサーバ
７ ＮＡＴ装置
８ ＳＩＰサーバ
９ 通信回線
１０ スコープ
１００ ＳＩＰメッセージ
１１０ ＲＴＰストリーム
１２０ ＳＩＰプロクシ−ＲＴＰプロクシ間連携メッセージ
１３０ ＳＩＰプロクシ−プレゼンスサーバ間連携メッセージ
３１ ＩＦ
３２ ＣＰＵ
３３ メモリ
３４ データパス
３３０ セッション管理テーブル
３３１ 呼制御プログラム
３３２ 経路決定プログラム
３３３ 処理情報取得プログラム
３３４ ＲＴＰプロクシ連携プログラム
３３５ プレゼンスサーバ連携プログラム
３３７ 静的処理情報テーブル。

Claims (5)

1. 通信端末と他のセッション中継装置とに接続されたセッション中継装置であって、
   上記通信端末または上記セッション中継装置から呼制御メッセージを受信する送受信部と、
   上記呼制御メッセージの通過する経路上での自装置の位置の情報と、上記呼制御メッセージが属するセッションが必要とする処理に関する情報とに基づいて、上記処理を自装置で実行するか否かを決定する制御部を有するセッション中継装置。
2. 請求項１記載のセッション中継装置であって、
   上記送受信部は、上記呼制御メッセージが属するセッションが必要とする処理を自装置で実行したか否かの情報が付加された上記呼制御メッセージを送信することを特徴とするセッション中継装置。
3. 請求項１記載のセッション中継装置であって、
   上記呼制御メッセージが属するセッションが必要とする処理は２つ以上の独立した処理であることを特徴とするセッション中継装置。
4. 請求項１記載のセッション中継装置であって、
   記憶部を備え、
   上記記憶部には、
   上記呼制御メッセージの通過する経路上での自装置の位置の情報を取得するプログラムと、
   上記呼制御メッセージが属するセッションが必要とする処理に関する情報を取得するプログラムと、
   上記呼制御メッセージの通過する経路上での自装置の位置の情報と、上記呼制御メッセージが属するセッションが必要とする処理に関する情報とに基づいて、上記処理を自装置で実行するか否かを決定するプログラムとが記憶されており、
   上記制御部は、上記記憶部に記憶された各プログラムを実行することを特徴とするセッション中継装置。
5. 請求項４記載のセッション中継装置であって、
   上記処理を自装置で実行するか否かを決定するプログラムは、上記処理ごとに追加または削除できることを特徴とするセッション中継装置。

Images