JP5594970B2 - セッション開始プロトコルメッセージを優先度付けするシステム及び方法 - Google Patents

Description

本発明は概略としてコンピュータネットワークに関し、より具体的にはインターネットプロトコル（ＩＰ）ベースのコンピュータネットワークに関する。

本章では、以下及び特許請求の範囲に記載される、本発明の種々の側面に関する技術の様々な側面に目を向ける。この説明は、本発明の種々の側面についてのより深い理解を促進するバックグランドとなる情報を与えることにおいて有用なものとなる。従って、これらの記載は上記の観点で読まれるべきであって、従来技術の認定として読まれるべきではないことが分かる。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、ビデオ、オーディオ、インスタントメッセージング、オンラインゲームのような種々のマルチメディアサービス、及び／又はインターネットのようなＩＰネットワークを介した電話呼を提供するための標準化されたアーキテクチャである。ＩＭＳ標準は種々の異なる通信プロトコルを採用してこれらのマルチメディアサービスを確立し、及び管理する。これらの標準の１つであってセッション開始プロトコル（ＳＩＰ）として知られるものは、ＩＭＳネットワーク内のユーザ（以下、「ユーザエージェント」という）の間の通信セッションを生成し、管理し、及び終了するための標準規格を提供する。ＩＭＳネットワークにおけるユーザエージェントは、ワイヤレス電話、ボイスオーバーＩＰ電話、コンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、あるいは様々な他の適切な通信装置等である。ＳＩＰ標準の一例は第３世代パートナーシッププロジェクト（３ＧＰＰ）によって普及した３ＧＰＰ＿ＳＩＰ標準である。

ＳＩＰ標準は、ＳＩＰプロキシサーバやＳＩＰバックトゥバック・ユーザエージェント（Ｂ２ＢＵＡ）のような２つのユーザエージェント間で１以上のＳＩＰサービスを介してやり取りされるＳＩＰメッセージとして知られる様々な送信方式を採用する。ＳＩＰメッセージは通常、特定の通信セッションの確立及び分解に関係する情報を含む。例えば、ＳＩＰメッセージはどのユーザエージェントが通信を開始しているのか、その通信に対してどのＩＰポートを使うのか、どのような復号方式が当てはまるのか、等を記述する。あるユーザエージェントが他のユーザエージェントと通信しようとするとき、開始ユーザエージェントはＳＩＰメッセージをＩＭＳネットワーク内のプロキシサーバに送信する。そして、このプロキシサーバはＳＩＰメッセージを途中の１以上の他のプロキシサーバによって送信先ユーザエージェントに送信する。開始ユーザエージェントは普通は受信ユーザエージェント及び／又は通信セッションの接続又はサポートを与えるアプリケーションサーバの正確なアドレスを知らないので、通常はプロキシサーバが用いられる。このように、ＳＩＰメッセージが、リクエストを適当な場所へ転送するためのプロキシサーバへ送信される。所定数（例えば、１２）のＳＩＰメッセージが交換された後に、その２つのユーザエージェント間の通信セッションが確立される。

無数の潜在的ユーザエージェント及びプロキシサーバを有する巨大なＩＭＳネットワークにおいては、ある時間に数千又はそれ以上のＳＩＰメッセージが個々のプロキシサーバによって処理されることになる。従来のＩＭＳネットワークはこれらのリクエストをファーストイン・ファーストアウト（ＦＩＦＯ）方式で処理するように構成されている。言い換えると、プロキシサーバはＳＩＰメッセージを受信した順番通りに処理するように構成されている。例えば、プロキシサーバがその最初のＳＩＰメッセージを受信すると、そのメッセージを処理し始める。他のＳＩＰメッセージが受信された場合、プロキシサーバは最初のメッセージを処理する一方で、（他のＳＩＰメッセージは）ＳＩＰメッセージ待ち行列内で最初のメッセージの後に配置される。さらに他のＳＩＰメッセージが受信されると、プロキシサーバが最初のメッセージを処理する一方、（さらなる他のＳＩＰメッセージは）ＳＩＰメッセージ待ち行列内で２番目のメッセージの後に配置される。プロキシサーバは最初のメッセージの処理を終了すると、どれだけのメッセージが待ち行列内にあるかにかかわらず、そして待ち行列内のメッセージの属性にかかわらず、２番目のメッセージの処理を開始する。
以下に記載される実施例の１以上は上記の側面の１以上に向けられている。

開示される実施例に対応する特定の側面を以下に説明する。なお、これらの側面は単に本発明のある側面が持つ概要を提供するために開示され、これらの側面は本発明の範囲を限定することを意図するものではない。当然に、本発明は以下に説明しない種々の側面をも包含する。

セッション開始プロトコル（ＳＩＰ）メッセージを優先度付けするためのシステム及び方法が提供される。より具体的には、一実施例として、ネットワーク内のＳＩＰメッセージを優先度付けするための方法が提供され、その方法は、ＳＩＰメッセージを第１の順序でネットワークにおける１以上の他のサーバから受信するステップであって受信されたＳＩＰメッセージ各々が１以上の優先度インジケータを含むようなステップ、１以上の優先度インジケータに基づいて受信ＳＩＰメッセージを第２の順序でスケジューリングするステップ、及びスケジューリングされたＳＩＰメッセージを第２の順序で処理するステップからなる。
以下の詳細な説明を読み、添付の図面を参照すれば本発明の有利な効果が明らかとなる。

本発明の１以上の特定の実施例を以下に記載する。これらの実施例の簡潔な説明の提供を心がけるために、明細書においては現実の実施における全ての構成が記載されているわけではない。技術開発や設計プロジェクトのような現実の実施への展開においては、その実施に特有の多数の決定が行われて、システムに関する準拠事項や事業に関する制約のように実施内容によって変わり得る開発者の特定の目標が達成されるであろうことが分かる。さらに、そのような開発へ向けての労力は複雑かつ時間のかかるものではあるが、本開示の恩恵を受ける当業者にとっては、それは設計、作製及び製造の通常の作業の範疇であることが分かる。

上述したように、従来のＳＩＰシステム内のセッション開始プロトコル（ＳＩＰ）メッセージはファーストイン・ファーストアウト（ＦＩＦＯ）方式でスケジューリングされる。しかし、このＦＩＦＯスケジューリングにはいくつかの不利な点がある。第１に、ＦＩＦＯスケジューリングは、システム効率を上げるようなＳＩＰメッセージが先に処理されることを可能とするものではないので、ＦＩＦＯスケジューリングは効率的ではない。例えば、通信セッションを終了するためのメッセージのような特定のＳＩＰメッセージがその他のタイプのＳＩＰメッセージよりも優先されれば、ＩＭＳネットワーク全体の総合効率を向上することができそうである。第２に、ＦＩＦＯスケジューリングは種々のタイプのユーザサービス間でサービスの区別を可能とするわけでもない。言い換えると、従来のＦＩＦＯシステムでは、全てのＳＩＰメッセージが、それが時間に影響を受けるものであってもなくても同様に扱われる。例えば、プッシュ・トゥ・トークのサービスのような特定のサービスは他のタイプのサービスよりも回線上で「待つこと」に適していないが、ＦＩＦＯシステムは種々のタイプのサービス間での区別をすることができない。第３に、ＦＩＦＯスケジューリングはサービスのクラスに基づく区別も許可していない。例えば、従来のＳＩＰサービスは全てのＳＩＰメッセージを同等に扱うように構成され、これによってＩＭＳネットワーク管理者がアップグレードされたオプション又はプレミアムサービスオプションをより高いコストで提供することが妨げられる。第４に、ＦＩＦＯスケジューリングポリシーの下で入着メッセージを処理する１以上のネットワーク要素によってメッセージがループバックできる場合に、ネットワークが不安定になることが数学的に証明されている。ＩＭＳネットワークはＳＩＰメッセージがＳＩＰプロキシを介してループバックすることを可能とするので、これらのＳＩＰプロキシがＦＩＦＯスケジューリングを使用する場合、ネットワークは潜在的な不安定状態に曝される。

ＳＩＰメッセージの従来のＦＩＦＯスケジューリングにおける上記不利益を鑑みると、ＳＩＰメッセージを優先度付けするシステム又は方法は有利である。このように、下記の１以上の実施例はＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークにおいてＳＩＰメッセージを優先度付けするためのシステム及び方法に向けられる。より具体的には、ここに記載される１以上の実施例は、入着ＳＩＰメッセージに対する優先度を決定し、入着メッセージの優先度をＳＩＰサーバの待ち行列で送信を待っている他のＳＩＰメッセージの優先度と比較し、その比較結果に基づいて入着ＳＩＰメッセージを待ち行列中に配置するように構成されたＳＩＰサーバに向けられている。

図面を参照するにあたり、まず図１を見ると、一実施例による代表的ＳＩＰメッセージのブロック図が示され、全体として符号１０で指定されている。図示するように、ＳＩＰメッセージ１０は３つの部分からなり、それらは、スタートライン１２、ヘッダ１４及びメッセージボディ１６である。スタートライン１２はＳＩＰバージョン、ＳＩＰメッセージのタイプ及びＳＩＰアドレスを含む。スタートラインのＳＩＰメッセージタイプは種々のＳＩＰリクエストメッセージタイプを含み、それらは、限定するわけではないが、ユーザエージェントをセッションに招くためのＩＮＶＩＴＥ、ＳＩＰメッセージの受信を確認するためのＡＣＫ、ＳＩＰ装置を他のユーザエージェントに照会するためのＲＥＦＥＲ、メディアタイプを照会するためのＯＰＴＩＯＮ、セッションを終了するためのＢＹＥ、係属中のやり取りを取り消すためのＣＡＮＣＥＬ、ＩＰアドレスをＩＭＳネットワークに追加するためのＲＥＧＩＳＴＥＲ、及び／又はインスタントメッセージを開始するためのＭＥＳＳＡＧＥ等であればよい。

ヘッダ１４は、図２に示すＩＭＳネットワークのようなＩＭＳネットワークによってＳＩＰメッセージ１０のルーティングに関係する情報を含む複数のメッセージヘッダフィールドを含む。例えば、ヘッダ１４は、ＳＩＰメッセージ１０を発信したユーザエージェントのアイデンティティ、ＳＩＰメッセージ１０が向けられた受信者のアイデンティティ、ＳＩＰメッセージのサブジェクト、メッセージのサービスタイプ（例えば、アプリケーションのタイプ）、ＳＩＰメッセージ１０がＩＭＳネットワーク内で行ったホップ等を示すフィールドを含んでいればよい。ヘッダ１４は、サービス品質（ＱｏＳ）関連のデータを記憶するフィールド、サービスグレード（ＧｏＳ）のデータを記憶するフィールド、及び／又はＩＭＳネットワーク内のユーザエージェント若しくはサービス間での区別を可能とする他のデータを記憶するフィールドを含んでいてもよい。

さらに、ヘッダ１４はＳＩＰメッセージ１０に対するタイプスタンプを記憶するように構成された１以上のフィールドを含んでいてもよい。例えば、ヘッダ１４は、ＳＩＰメッセージ１０がＩＭＳネットワークに入った時を示すタイムスタンプ（以下、「ネットワーク進入タイムスタンプ」という）を含むフィールドを含んでいてもよい。ヘッダ１４はまた、ＳＩＰメッセージ１０がＩＭＳネットワーク内のいずれかのサーバ（例えば、プロキシサーバ）に入った及び／又は出た時を示すタイムスタンプを記憶するフィールドを含んでいてもよい。

ヘッダ１４はまた、ＳＩＰメッセージ１０の累積遅延を記憶するフィールドを含んでいてもよい。例えば、ＳＩＰメッセージ１０がＩＭＳネットワーク内のサーバに到着したときに、現在のシステム時刻からネットワーク進入タイムスタンプを差し引くことによって、ＳＩＰメッセージ１０がＩＭＳネットワークに入ってから経過した合計時間を反映して遅延フィールドが更新されるようにしてもよい。

上述したように、ヘッダ１４はＳＩＰメッセージ１０の相対的優先度の表示となる種々のヘッダフィールドを含み得る。一実施例として、これらの追加的フィールドが従来のＳＩＰメッセージヘッダに付加されてこの情報を記憶するようにしてもよい。例えば、ＳＩＰメッセージ１０の累積遅延及び／又は累積処理時間を表示するフィールドがヘッダ１４に付加されるようにしてもよい。他の実施例として、既存の標準化ＳＩＰフィールドが用いられて優先度情報を記憶するようにしてもよい。例えば、３ＧＰＰ＿ＳＩＰメッセージ規格はＳＩＰメッセージ１０がＩＭＳネットワーク内で行ったホップ数を示すフィールドを既に含んでいる。さらに他の実施例として、３ＧＰＰ標準で概略が規定されているヘッダフィールドのような標準化されたヘッダフィールドが優先度情報を記憶するように修正されてもよい。例えば、３ＧＰＰ標準はＳＩＰメッセージが９１１緊急呼に関係するか否かを示す「優先」フィールドを含む。一実施例では、このフィールドは上述した１以上の優先度インジケータを記憶するように修正される。しかし、これらのヘッダフィールドのオプションは排他的ではないことが分かる。このように、優先度情報が新たなヘッダフィールド、標準ヘッダフィールド、修正された標準ヘッダ、又はこれらの組み合わせに記憶され得る。

さらに、当業者であれば、上述のヘッダ１４のヘッダフィールドはヘッダ１４における多数の可能なフィールドのうちのいくつかの例示にすぎないことが分かるはずである。このように、代替的実施例として、上述のヘッダフィールドに加えて、又はその代わりに広範な種類の適切なヘッダフィールドがヘッダ１４内に含まれ得る。例えば、一実施例では、ヘッダ１４は６５個以上のフィールドを含む場合もある。

ＳＩＰメッセージ１０はまたメッセージボディ１６を含み、これは通信セッションを確立するために使用される情報を含む。例えば、一実施例として、メッセージボディ１６は、ＳＩＰメッセージ１０の発信者についての情報、通信セッションに使うポート、利用可能なメディアタイプについての情報、及び／又は通信セッションに使うコードについての情報を提供するセッション記述プロトコル（ＳＤＰ）ペイロードを含んでいてもよい。代替的実施例として、適切な通信セッションに関する情報がメッセージボディ１６に含まれるようにしてもよい。

上述したように、ＳＩＰメッセージ１０によってＩＭＳネットワーク内の２つのユーザエージェント間の通信セッションの確立が促進される。ここで、図２には、一実施例による、ＳＩＰメッセージ１０のようなＳＩＰメッセージを優先度付けするように構成された代表的ＩＭＳネットワーク２０のブロック図を示す。ネットワーク２０は発信元ユーザエージェント２２及び送信先ユーザエージェント２４を含む。ユーザエージェント２２及び２４は、（有線か無線の）電話、コンピュータ、ＰＤＡ等の多数の適切な電気通信装置のうちのいずれかであればよい。

説明の便宜上、ＩＭＳネットワーク２０の以下の記載は、ユーザエージェント２２と２４の間でのＳＩＰプロキシサーバを介した新たな通信セッションをリクエストするためにＳＩＰメッセージ１０（言い換えると、ＩＮＶＩＴＥメッセージタイプのＳＩＰメッセージ）を用いることに焦点を当てて説明する。しかし、ＩＮＶＩＴＥメッセージタイプはＳＩＰメッセージタイプの一例に過ぎず、それゆえ他を排するものではない。従って、他の実施例では、ＩＮＶＩＴＥメッセージタイプの他に他のＳＩＰメッセージタイプがＩＭＳネットワーク２０内で送信され得る。さらに、他の実施例では、バックトゥバック・ユーザエージェント（Ｂ２ＢＵＡ）又は他の適切なタイプのサービスもＩＭＳネットワーク２０内で採用され得る。

ユーザエージェント２２は、ユーザエージェント２４を招いてユーザエージェント２２との通信セッションに参加するようにするためにＩＮＶＩＴＥメッセージタイプのＳＩＰメッセージ１０を用いることができる。より具体的には、ユーザエージェント２２はＳＩＰメッセージ１０をＩＮＶＩＴＥメッセージタイプで作成する。ユーザエージェント２２はＳＩＰメッセージ１０を作成した後、ユーザエージェント２２とＩＭＳネットワーク２０の他の構成要素の間のインターフェイスを提供するネットワークゲートウェイ２６にＳＩＰメッセージ１０を送信する。種々の実施例において、ゲートウェイ２６は無線モデム、無線基地局、有線モデム、又は他の何らかの適当な形式のネットワーク接続構成等である。

ゲートウェイ２６はＳＩＰメッセージ１０を受信すると、ＳＩＰメッセージ１０をプロキシサーバ２８ａに転送する。（以下に記載するプロキシサーバ２８ｂ、２８ｃ及び２８ｄと同様に）プロキシサーバ２８ａはＳＩＰリクエスト及び応答をＩＭＳネットワーク２０によって転送するように構成された特別なサーバである。ユーザエージェント２２及び２４はプロキシサーバ２８ａ−ｄがなくても通信できるが、以下のように、プロキシサーバ２８ａ−ｄはユーザエージェント２２と２４の間の通信セッションの管理を補助する種々の実用上のサービスを提供する。例えば、プロキシサーバ２８ａ−ｄはリクエストをＩＭＳネットワーク２０内でルーティングし、セキュリティを認証及び提供し、特定のサービスについてユーザエージェント２２及び２４を許可し、呼のルーティングポリシーを実行し、ユーザエージェント２２及び２４に他の機能を提供し、及び／又はＩＭＳネットワーク２０の使用を追跡するように構成され得る。

図２に示すように、ＳＩＰメッセージ１０はゲートウェイ２６、及び途中の複数のプロキシサーバ２８ａ−ｄを介してユーザエージェント２４へと進む。ＩＭＳネットワーク２０内のこの論理経路は「制御パス」といわれる。制御パスはＳＩＰメッセージがＩＭＳネットワーク内を通過する経路であるが、通信セッションが確立されると、ユーザエージェント２２と２４の間でデータを送信するために、より直接的なものとなる「メディアパス」（これについては後述する）が採用される。

ＳＩＰメッセージ１０は制御パスに沿ってプロキシサーバ２８ｂに進む。プロキシサーバ２８ｂはＳＩＰメッセージ１０を１以上のアプリケーションサーバ３０ａ及び３０ｂを介してルーティングするよう構成される。アプリケーションサーバ３０ａ及び３０ｂはＩＭＳネットワーク２０におけるエンドユーザサービスをホストするコンピュータである。例えば、アプリケーションサーバ３０ａ−３０ｄの各々は１以上のビデオ、オーディオ、インスタントメッセージング、プッシュ・トゥ・トーク機能、ボイスオーバーＩＰ電話呼等のようなデータ及び／又はマルチメディアサービスをホストするものであればよい。図２には２つのアプリケーションサーバ３０ａ及び３０ｂが示されているが、ＩＭＳネットワーク２０で利用可能なマルチメディアサービスの数及びユーザエージェントの数によって、適正な数のアプリケーションサーバ３０ａ−ｄがＩＭＳネットワーク２０に含まれるようにすればよい。

ＳＩＰメッセージ１０は、（ＳＩＰメッセージ１０において規定される）ユーザエージェント２２によってリクエストされたマルチメディアサービスと関連するアプリケーションサーバ３０ａ−ｄにルーティングされる。例えば、ユーザエージェント２２がユーザエージェント２４とのインスタントメッセージセッションを確立することをリクエストした場合、プロキシサーバ２８ｂはＳＩＰメッセージ１０を、例えばアプリケーションサーバ３０ａのようなインスタントメッセージングをサポートするアプリケーションサーバに送信する。ＳＩＰメッセージ１０をアプリケーションサーバ３０ａ−ｄを通過させてＳＩＰプロキシ２８ｂに戻す処理は「スパイラリング」として知られる。アプリケーションサーバ３０ａはＳＩＰメッセージ１０を受信すると、このアプリケーションサーバがこの通信セッションについての制御パスの常時メンバーとなるように、ＳＩＰメッセージ１０のメッセージボディ１６を修正してアプリケーションサーバ３０ａのＩＰアドレスを含める。アプリケーションサーバ３０ａはＳＩＰメッセージの他の属性を修正するよう構成されていてもよい。例えば、アプリケーションサーバは、ＳＩＰメッセージがアプリケーションサーバ３０ａに到着し又は出て行った時間を示すタイムスタンプをＳＩＰメッセージ１０の後ろに付加するようにしてもよい。以下に記載するように、このタイムスタンプはＳＩＰメッセージ１０の優先度付けを促進するものとなる。

プロキシサーバ２８ｂがＳＩＰメッセージをアプリケーションサーバ３０ａ（アプリケーションサーバ３０ａは修正したメッセージをプロキシサーバ２８ｂに返送する）に送信した後、プロキシサーバ２８ｂは他のアプリケーションサーバが関与されることを必要としているかを判断しなければならない。それを必要としている場合、プロキシサーバ２８ｂは新たに修正したメッセージをアプリケーションサーバ３０ｂに送り、アプリケーションサーバ３０ｂはメッセージ１０の第３の実施例をプロキシサーバ２８ｂに転送する。

この時点で、プロキシサーバ２８ｂはＳＩＰメッセージ１０をプロキシサーバ２８ｃに送信できる。図２に示すように、プロキシサーバ２８ｃはＳＩＰメッセージ１０をアプリケーションサーバ２８ｃ及び２８ｄの一方又は両方にスパイラリングすることができる。アプリケーションサーバ３０ａ及び３０ｂについて、アプリケーションサーバ３０ｃ又は３０ｄがＳＩＰメッセージ１０を受信すると、当該アプリケーションサーバがこの通信セッションの制御パスの常時メンバーとなるように、ＳＩＰメッセージ１０のメッセージボディ１６を修正してアプリケーションサーバ３０ｃ又は３０ｄのＩＰアドレスを含める。一実施例では、アプリケーションサーバ３０ａ及び３０ｂがユーザエージェント２２の代わりにアプリケーションを実行するように構成されるとともに、アプリケーションサーバ３０ｃ及び３０ｄがユーザエージェント２４の代わりにアプリケーションを実行するように構成される。

なお、説明の目的のみのために、アプリケーションサーバ３０ａ−ｄがプロキシサーバ２８ｂに結合されるように図示されていることが分かる。従って、代替の実施例では、アプリケーションサーバ３０ａ−ｄはプロキシサーバ２８ａ−ｄのうちの他の１つのプロキシサーバ又は複数のプロキシサーバ２８ａ−ｄに結合されていてもよい。さらに、４つのプロキシサーバ２８ａ−ｄは例示目的のみで図示されていることが分かる。従って、代替の実施例として、ＳＩＰメッセージ１０がユーザエージェント２２からユーザエージェント２４までの途中で適正な数のプロキシサーバを経由するようにしてもよい。さらに、図２に図示していないが、他のタイプのＳＩＰサーバがプロキシサーバ２８ａ−ｄに結合されるようにしてもよい。これらの追加的なＳＩＰサーバは、限定するわけではないが、ホーム加入者又はロケーションサーバ、ドメインネームサーバ、及び方向変更サーバ等である。

プロキシサーバ２８ｃはＳＩＰメッセージを制御パスに沿ってプロキシサーバ２８ｄに送信し、プロキシサーバ２８ｄはＳＩＰメッセージ１０をゲートウェイ３２に送信する。ゲートウェイ３２は、ゲートウェイ２６と同様に、ＩＭＳネットワーク２０の他の構成要素とユーザエージェント２４の間の接続構成である。種々の実施例において、ゲートウェイ３２は無線モデム、無線基地局、及び／又は有線接続構成等であればよい。

ユーザエージェント２４がＳＩＰメッセージ１０を受信すると、ユーザエージェント２４は応答ＳＩＰメッセージをＩＭＳネットワーク２０を介して制御パスに沿って返送する。所定数（代表的３Ｇシステムでは６）のＳＩＰメッセージが巡回した後に、ユーザエージェント２２との通信セッションが確立されるようにしてもよい。確立されると、その後に続くユーザエージェント２２とユーザエージェント２４の間、又はユーザエージェント２２及び２４とアプリケーションサーバ３０ａ−ｄの間の非ＳＩＰ送信は、プロキシサーバ２８ａ−ｄをバイバスして、ユーザエージェント２２と２４の間を非ＳＩＰルータ及び／又はスイッチ３４を介して直接伝搬することができる。なお、当然に、ＳＩＰ通信及び非ＳＩＰ通信の双方とも制御パスに沿ってプロキシサーバ２８ａ−ｄを通過することもできる。

先に概説したように、従来のＳＩＰサーバは受信ＳＩＰメッセージ１０をファーストイン・ファーストアウト（ＦＩＦＯ）の順序で処理するように構成されている。しかし、この従来のＦＩＦＯの構成には多くの不利な点や非効率な点がある。このため、プロキシサーバ２８ａ−ｄ及び／又はアプリケーションサーバ３０ａ−ｄのようなＩＭＳネットワーク２０内の１以上のＳＩＰサーバは入着ＳＩＰメッセージ１０を優先度付けするように構成される。ここで、図３は一実施例によるＳＩＰメッセージを優先度付けするように構成された代表的ＳＩＰプロキシサーバ２８ａのブロック図である。なお、当然に、以下の説明はＳＩＰプロキシサーバ２８ａ以外のあらゆる適当なタイプのＳＩＰサーバに対する適用例となる。

図３に示すように、プロキシサーバ２８ａはネットワークモジュール４０、ＳＩＰスケジューリングモジュール４２、及び処理モジュール４４を含む。ネットワークモジュール４０はプロキシサーバ２８ａとＩＭＳネットワーク２０における他の構成要素とのジャンクションとして動作するよう構成されていればよい。一実施例として、ネットワークモジュール４０はスレッドとして知られる複数のソフトウェア構成物を含み、これらはプロキシサーバ２８ａの１以上のポートからＳＩＰメッセージを受信するよう構成され得る。例えば、ネットワークモジュール４０はＵＤＰポートからＳＩＰメッセージを受信するためのユーザ・データグラム・プロトコル（ＵＤＰ）スレッド及びＴＣＰポートからＳＩＰメッセージを受信するためのトランスミッション・コントロール・プロトコル（ＴＣＰ）スレッドを含む。なお、ＵＤＰスレッド４６及びＴＣＰスレッド４８は単なる例示である。従って、代替の実施例として、ネットワークモジュールはストリーム・コントロール・トランスミッション・プロトコル（ＳＣＴＰ）又は他の適当な通信プロトコルを受信するように構成されていてもよい。

ネットワークモジュール４０は受信ＳＩＰメッセージ１０をＳＩＰスケジューリングモジュール４２に送信し、ＳＩＰスケジューリングモジュール４２は受信ＳＩＰメッセージの待ち行列を保持し、新たに受信したＳＩＰメッセージをその待ち行列内で優先度付けする。例えば、図４は一実施例によるＳＩＰメッセージを優先度付けするための代表的技法６０を示すフローチャートである。一実施例では、技法６０はＳＩＰスケジューリングモジュール４２によってＪＡＩＮ（登録商標）ＳＩＰに準拠したＪＡＶＡ（登録商標）スタックを用いて実行され得る。例えば、技法６０はルーセントテクノロジーズ社によって生産されるＭｉＬｉｆｅ（登録商標）サーバで実行され得る。代替の実施例として、技法６０はプロキシサーバ２８ａ−ｄ、アプリケーションサーバ３０ａ−ｄ、ゲートウェイ２６及び３２、及び／又はバックトゥバック・ユーザエージェント（図２には不図示）のようなＩＭＳシステムの他の構成要素によって実行されるようにしてもよい。さらに、一実施例として、ＳＩＰスケジューリングモジュール４２は異なるプロパティのＳＩＰメッセージ１０を記憶するように構成された複数の待ち行列を含んでいてもよい。例えば、ある待ち行列が高い方の優先度のメッセージを記憶し、他の待ち行列が低い方の優先度のメッセージを記憶するようにしてもよい。

図においてブロック６２に示すように、技法６０はスケジューリングモジュール４２で入着ＳＩＰメッセージ１０を受信することを開始する。入着ＳＩＰメッセージ１０が受信されると、ブロック６４に示すように、ＳＩＰスケジューリングモジュール４２は入着ＳＩＰメッセージ１０の優先度を決定する。種々の実施例において、ＳＩＰスケジューリングモジュール４２は、入着ＳＩＰメッセージ１０のようなＳＩＰメッセージの優先度を決定するための種々の異なる適切な優先度付け技法を採用することができる。

そのような代表的技法は特定のＳＩＰメッセージの累積遅延（以下、「ネットワークエイジ」ともいう）に基づいてＳＩＰメッセージ１０を優先度付けすることを含む。より具体的には、上述のように、ＳＩＰメッセージ１０はネットワークエンティティのタイムスタンプを含み得る。現在のシステム時刻からこのタイムスタンプを引くことによって、プロキシサーバ２８ａはＳＩＰリクエストがＩＭＳネットワーク２０でどれくらいの間処理されないでいたか、即ちＳＩＰリクエストのネットワークエイジ、を特定することができる。あるいは、ＳＩＰメッセージ１０がＳＩＰメッセージ１０についての累積した処理及び待機時間を記憶し、この記憶された値をＳＩＰメッセージ１０のネットワークエイジとして使用してもよい。言い換えると、ＳＩＰメッセージのネットワークエイジはＳＩＰメッセージ１０がプロキシサーバ２８ａ−ｄの制御下にある時間の合計として評価され得る。

ＳＩＰリクエストのネットワークエイジが特定されると、ＳＩＰスケジューリングモジュール４２はこの情報を用いてＳＩＰメッセージ１０の優先度を決定する。一実施例として、ネットワークエイジ自体がメッセージの優先度を示すようにしてもよい。そのような実施例では、ＳＩＰスケジューリングモジュール４２はＳＩＰメッセージ１０をネットワークエイジだけを用いてランク付けするように構成される（例えば、より高いネットワークエイジをもつＳＩＰメッセージがより高い優先度を有し、より低いネットワークエイジをもつＳＩＰメッセージがより低い優先度を有する等）。

なお、他の実施例として、ネットワークエイジがＳＩＰメッセージ１０に記憶されたサービスタイプと組み合わされて、ＳＩＰメッセージ１０の優先度を決定するようにしてもよい。ここで、図５はネットワークエイジ及びサービスタイプを用いてＳＩＰメッセージ１０の優先度付けを決定するための一実施例による代表的技法６４を示すフローチャートである。本実施例では、まずＳＩＰメッセージ１０のネットワークエイジが上記のやり方で特定される（ブロック７０）。次に、ブロック７２に示すように、ＳＩＰスケジューリングモジュール４２はサービスタイプ情報（例えば、プッシュ・トゥ・トーク、ｅメール等）をＳＩＰメッセージ１０から読み取る。サービスタイプが読み取られると、ブロック７４に示すように、プロキシサーバはサービスタイプに関連するＱｏＳ目標時間を特定する。ＱｏＳ目標時間は、ＳＩＰメッセージのサービスタイプに対するサービス標準の品質の維持を促進する、ＩＭＳネットワーク２０を通過する目標伝送時間である。例えば、プッシュ・トゥ・トークサービスは通常、ＳＩＰメッセージを０．５秒以内に、ボイスオーバーＩＰは１秒以内に伝送することを目標としている。

ＳＩＰメッセージ１０についてのＱｏＳ目標時間が特定されると、ブロック７６に示すように、プロキシサーバ２８ａはＱｏＳ目標時間をＳＩＰメッセージ１０のネットワーク「エイジ」と比較する。比較がなされると、ブロック７８に示すように、プロキシサーバ２８ａはネットワークエイジがどれだけＳＩＰメッセージのＱｏＳ目標時間に「近い」かに基づいて優先度値を割り当てる。例えば、ＱｏＳ目標時間に近いか又はそれを過ぎたネットワークエイジのＳＩＰメッセージは高い優先度に割り当てられ、ＱｏＳ目標時間から遠いものは低い優先度値に割り当てられる。一実施例では、優先度値はネットワークエイジがどの程度ＱｏＳ目標時間に近いか（又はそれを過ぎてしまっているか）及びこの目標の違反に対するアプリケーションの許容度に関連する。

図４のブロック６４に戻り、他の実施例として、入着メッセージの優先度を決定するステップが、ＳＩＰメッセージ１０のヘッダ１４に記憶された１以上の優先度インジケータに基づく優先度をＳＩＰメッセージ１０に割り当てるステップを含んでいてもよい。上述のように、ヘッダ１４がＳＩＰメッセージ１０を発信するユーザエージェントのアイデンティティ、ＳＩＰメッセージ１０の意図された受信者のアイデンティティ、ＳＩＰメッセージのサブジェクト、メッセージのサービスタイプ（例えば、アプリケーションのタイプ）、ＳＩＰメッセージ１０がＩＭＳネットワーク内で行った「ホップ」数、及び／又はＳＩＰメッセージ１０に適用される処理リソースの蓄積量の表示を示すフィールドを含んでいてもよい。さらに、ヘッダ１４はサービス品質（ＱｏＳ）に関するデータを記憶するフィールド、サービスのグレード（ＧｏＳ）のデータを記憶するフィールド、及び／又はＩＭＳネットワークにおけるユーザエージェント若しくはサービス間の区別を可能とするデータを記憶する他の適当なフィールドを含んでいてもよい。

従って、上述のヘッダフィールド又は他の適当な優先度表示ヘッダフィールドに記憶された優先度インジケータの１以上がＳＩＰメッセージ１０の優先度を決定するために採用されることができる。より具体的には、優先度はサービスのタイプ、ＱｏＳに関するデータ、ＧｏＳに関するデータ、ＳＩＰメッセージ１０が行ったホップ数、ＳＩＰメッセージ１０について費やされた処理時間の累積量等に関連するものであればよい。例えば、優先度がサービスのタイプに基づく一実施例では、あるタイプのサービス（例えばプッシュ・トゥ・トーク）の全ＳＩＰメッセージが、他のタイプのサービス（例えばボイスオーバーＩＰ）の全ＳＩＰメッセージよりも優先され、それが他のタイプのサービスよりも優先される等としてもよい。

より具体的には、本実施例では、ＳＩＰスケジューリングモジュール４２はＳＩＰメッセージ１０を受信すると、ＳＩＰメッセージ１０に記憶されたサービスタイプ（即ち、本実施例ではプッシュ・トゥ・トーク）を特定するようにしてもよい。ＳＩＰスケジューリングモジュール４２は、例示のサービスタイプであるプッシュ・トゥ・トークに関連する数値的な優先度値を決定する。優先度値は他のサービスタイプのメッセージとの比較におけるプッシュ・トゥ・トークメッセージの処理及び／又は再送信についての相対的優先度を反映する数値である。例えば、プッシュ・トゥ・トークサービスタイプについての優先度値を５、インスタントメッセージングＳＩＰメッセージについての優先度値を１として、より高い数値がより高い優先度のサービスタイプを示すようにすることができる。一実施例では、ＳＩＰスケジューリングモジュール４２が各ヘッダフィールド値に関連する数値のリスト（例えば、上記の例において、サービスタイプ各々に関連する数値のリスト）を記憶するようにしてもよい。

さらに他の例として、優先度値がサービスタイプではなくＧｏＳに基づく場合には、より高額なサービスプランを利用するユーザエージェント２２から発信されたＳＩＰメッセージが、より低額なサービスプランのユーザエージェント２２から発信されたＳＩＰメッセージよりも高い優先度値が割り当てられるようにしてもよい。ブロック６８に関連して後述するように、優先度値が割り当てられると、ＳＩＰスケジューリングモジュール４２は優先度値を用いて、処理スレッド５０及び５２のうちの一方に送信するための他の受信ＳＩＰメッセージにおけるＳＩＰメッセージ１０のランク付けをする。

同様に、他の実施例では、優先度値はＳＩＰメッセージ１０のスタートライン１２に記憶されたメッセージタイプに関連するものであってもよい。具体的には、ＳＩＰスケジューリングモジュール４２によって、あるメッセージタイプ、例えばＢＹＥ、のＳＩＰメッセージには、ＩＮＶＩＴＥメッセージタイプのような他のメッセージタイプのＳＩＰメッセージよりも高い優先度値が割り当てられてもよい。より具体的には、ＢＹＥメッセージは通信セッションを終了し、それが即座に処理されればＩＭＳネットワーク２０の輻輳を軽減するので、ＢＹＥメッセージタイプのＳＩＰメッセージにはより高い優先度値が割り当てられる。ＳＩＰメッセージ１０の優先度を決定する他の適切な技法は、ＳＩＰメッセージ１０について時間重み付け優先度値を計算することを含む。本実施例では、ＳＩＰメッセージ１０についての時間重み付け優先度値はＳＩＰメッセージのネットワークエイジ（上述）にＳＩＰメッセージの数値的な優先度値（上述）を乗ずることによって計算される。

例えば、優先度値がメッセージタイプに基づく場合、ＳＩＰスケジューリングモジュール４２はＳＩＰメッセージ１０に対する優先度値を決定し、その決定された優先度値にＳＩＰメッセージ１０のネットワークエイジを乗じてＳＩＰメッセージ１０の時間重み付け優先度値を得るようにしてもよい。例えば、最初のＳＩＰメッセージがＳＩＰスケジューリングモジュール４２にインスタントメッセージングのメッセージタイプで到着し、ネットワークエイジが０.６秒の場合、時間重み付け優先度値は０.６となる（インスタントメッセージングの優先度値を１として、１×０.６）。一方、２番目のＳＩＰメッセージがＳＩＰスケジューリングモジュール４２にプッシュ・トゥ・トークのメッセージタイプで到着し、ネットワークエイジが０.４秒の場合、時間重み付け優先度値は０.２となる（プッシュ・トゥ・トークメッセージの優先度値を５として、５×０.４）。このように、ＳＩＰスケジューリングモジュール４２は入着メッセージをヘッダ１４内の優先度インジケータ及びＳＩＰメッセージ１０のネットワークエイジの双方に基づいて優先度付けできる。後述するように、この優先度付けが採用されて、処理スレッド５０及び５２の１つによる処理のために他のＳＩＰメッセージにおける当該ＳＩＰメッセージ１０の順序を決めるようにしてもよい。

他の実施例では、ＳＩＰプロキシサーバ２８ａはメッセージの優先度を再調整してＳＩＰメッセージ１０のダウンストリームの処理を変えるように構成され得る。特に、ＳＩＰプロキシサーバ２８ａはＳＩＰメッセージ１０のヘッダ１４に記憶されたタイムスタンプの１以上を調整してもよい。例えば、ＳＩＰメッセージ１０の優先度を意図的に上げるために、ＳＩＰメッセージ１０がＩＭＳネットワーク２０に入った時間を示すタイプスタンプをＳＩＰプロキシサーバ２８ａが調整するようにして、ＳＩＰメッセージ１０が現実のネットワークエイジよりも大きいネットワークエイジを有することがＩＭＳネットワーク２０の他の構成要素、即ち、ダウンストリームの構成要素に分かるようにしてもよい。このようにネットワークエイジを調整することによって、ダウンストリームの構成要素（例えば、プロキシサーバ２８ａ）はそのＳＩＰメッセージ１０に同じ現実のネットワークエイジ（又は順番）の他のメッセージよりも高い優先度を与えることになる。好適なことに、この高い優先度によってＳＩＰメッセージ１０は他のメッセージよりも速く処理されることができ、これによってＩＭＳネットワーク２０を通過する合計伝送時間を減少させることができる。

より具体的には、一実施例では、ＳＩＰプロキシサーバ２８ａはまず、１以上の優先度インジケータ（例えば、上述したサービスタイプ、ＱｏＳファクタ等）を含むＳＩＰメッセージを特定するよう構成される。例えば、ＳＩＰプロキシサーバ２８ａは全てのプッシュ・トゥ・トークメッセージを特定する。次に、優先度インジケータを含むＳＩＰメッセージがＳＩＰプロキシサーバ２８ａに到着すると、ＳＩＰプロキシサーバ２８ａはＱｏＳ目標時間又はその近くを示すネットワークエイジ示すためにＳＩＰメッセージ１０のネットワーク進入タイムスタンプを調整する。一実施例では、ＳＩＰプロキシサーバはＱｏＳ目標時間の約８０％のネットワークエイジを示すようにネットワークエイジタイムスタンプを調整する。例えば、プッシュ・トゥ・トークメッセージが０.５秒のＱｏＳ目標時間の場合、ＳＩＰプロキシサーバ２８ａはネットワーク進入タイムスタンプを現在時刻の０.４秒前となるように変更する。タイムスタンプが変更されると、ＳＩＰプロキシサーバ２８ａは調整されたタイムスタンプに基づいてＳＩＰメッセージ１０を優先度付けする（ブロック６４参照）。

上記のやり方でＳＩＰメッセージ１０のネットワークエイジを調整することによって、ヘッダ１４内の優先度インジケータ及びＳＩＰメッセージ１０のネットワークエイジ双方に基づいて優先度付けするための他の技法が与えられる。好適なことに、ランク付けは専ら処理待ちの全ＳＩＰメッセージの相対ネットワークエイジに関連して行われるので、ＳＩＰメッセージ１０のネットワークエイジを調整することによってＳＩＰスケジューリングモジュール４２によるＳＩＰメッセージのランク付けが簡素化される（図４のブロック６６に関して詳細を後述する）。言い換えると、たとえ優先度付けが現実には優先度インジケータ及び現実のネットワークエイジ双方に基づくものであっても、ネットワークエイジはＳＩＰメッセージから優先度インジケータを考慮して調整されるので、ＳＩＰスケジューリングモジュール４２はネットワークエイジのみを用いて優先度を割り当てるよう構成され得る。

例えば、プッシュ・トゥ・トークメッセージについての目標時間が０.５秒の場合、プロキシサーバ２８ａは、プッシュ・トゥ・トークサービスに関連するＳＩＰメッセージを特定し、ヘッダ１４に記憶されたタイムスタンプを調整してプッシュ・トゥ・トークＳＩＰメッセージのネットワークエイジが０.３秒であることを示すように構成してもよい。逆に、ＳＩＰプロキシサーバ２８ａはインスタントメッセージングに関連するＳＩＰメッセージのタイムスタンプを調整しないように構成してもよい。このように、上述した時間重み付け優先度値と同様に、ＳＩＰメッセージがヘッダ１４からの優先度インジケータ及びネットワークエイジ双方に基づく優先度を割り当てられるようにしてもよい。なお、この例は単なる例示にすぎない。

さらに他の実施例では、ＳＩＰスケジューリングモジュール４２が、例えばＳＩＰプロキシサーバ２８ａ等のＳＩＰサーバの利用度に基づいてＳＩＰメッセージ１０を優先度付けするよう構成され得る。言い換えると、ＳＩＰスケジューリングモジュール４２は、ＳＩＰプロキシサーバ２８ａがどのくらい多く使用されているかによって、特定のタイプのＳＩＰメッセージを他のタイプのＳＩＰメッセージより前に優先度付けするように構成され得る。例えば、図６は一実施例による入着ＳＩＰメッセージ１０の優先度付けを決定するための他の代表的技法６４を示すフローチャートである。図６のブロック８０に示すように、技法６４はＳＩＰプロキシサーバ２８ａの利用度を特定することによって開始する。一実施例では、ＳＩＰスケジューリングモジュール４２はＳＩＰプロキシサーバ２８ａの利用度を追跡し、そのメモリにアクセスすることによってＳＩＰプロキシサーバ２８ａの利用度を特定するように構成され得る。

ＳＩＰプロキシサーバ２８ａがその容量又はその付近（例えば、図６のブロック８２に示す実施例における９０％ＣＰＵ利用度）で稼動している場合、ＳＩＰスケジューリングモジュールは通信セッションを終了するＳＩＰメッセージにより高い優先度値を割り当て、それによってＳＩＰプロキシサーバ２８ａの利用度が減少する（ブロック８４）。言い換えると、ネットワーク輻輳全体を低減するように作用するＳＩＰメッセージは、待機しなければならないメッセージよりも高い優先度値であるという性質上、待ち行列の先頭に「押し出される」。セッションを終了する例示のＳＩＰメッセージはメッセージタイプＢＹＥ又はＣＡＮＣＥＬのＳＩＰメッセージ等である。

一方、ＳＩＰプロキシサーバ２８ａが容量以下（例えば、ブロック８６に示す実施例における２０％以下のＣＰＵ利用度）で稼動している場合、ＳＩＰスケジューリングモジュールは、ＩＮＶＩＴＥ又はＭＥＳＳＡＧＥメッセージタイプのような新たな通信セッションを確立するＳＩＰメッセージにより高い優先度値を割り当てるように構成される（ブロック８８）。同様に、ＩＭＳネットワーク２０のネットワーク利用度又はＳＩＰプロキシサーバ２８ａのメモリ使用度に基づいていてもよい。例えば、ＳＩＰプロキシサーバ２８ａそのメモリの大部分を使い切っているような場合、ＳＩＰプロキシサーバ２８ａの要求量を減らすように作用するＳＩＰメッセージに優先度が与えられる。

当業者であれば、上述の優先度付け技法は単なる例示であり、排他的なものを意図していないことが分かるはずである。このように、ＳＩＰスケジューリングモジュール４２によって採用される優先度付け技法は上述の技法の１つを含んでいてもよいし、上述の技法の組み合わせを含んでいてもよいし、あるいは、他の適切な優先度付け技法を含んでいてもよい。

再度図３及び４に戻り、ブロック６６に示すように、技法６０はＳＩＰスケジューリングモジュール４２によって、ＳＩＰスケジューリングモジュール４２のＳＩＰメッセージ待ち行列（不図示）で待機している他のＳＩＰメッセージに対して入着ＳＩＰメッセージをランク付けすることを継続してもよい。ＳＩＰメッセージ待ち行列内のＳＩＰメッセージ各々はＳＩＰスケジュールモジュール４２へ到着すると優先度値を割り当てられるので、入着ＳＩＰメッセージをランク付けすることは、単に待ち行列のどこに入着ＳＩＰメッセージが配置されるかを決定することを含むことになる。言い換えると、入着ＳＩＰメッセージはそれより高い優先度ＳＩＰメッセージの後に配置されるが、それより低い優先度ＳＩＰメッセージの前には配置されない。

ブロック６８に示すように、入着ＳＩＰメッセージがランク付けされた後に、ＳＩＰスケジューリングモジュール４２は入着ＳＩＰメッセージを待ち行列内の適切な位置に挿入するよう構成される。入着ＳＩＰメッセージがＳＩＰメッセージ待ち行列の先頭に来ると、ＳＩＰスケジューリングモジュール４２は入着ＳＩＰメッセージを処理モジュール４４内の処理スレッド５０及び５２の一方にＳＩＰメッセージを送信する。ＵＤＰスレッド４６及びＴＣＰスレッド４８と同様に、処理スレッド５０及び５２は、ＳＩＰメッセージを処理し、それを他のプロキシサーバ２８ｂ−ｄの１つ、アプリケーションサーバ３０ａ−ｄの１つ、ゲートウェイ３２、又は他のコンピュータ若しくは電子装置に送信するように構成されたソフトウェア構成物である。

一実施例では、プロキシサーバ２８ａは、ＳＩＰメッセージが処理スレッド５０及び５２によって処理された後にＳＩＰメッセージを優先度付けするように構成されていてもよい。より具体的には、ＳＩＰプロキシサーバが使用中の場合、処理スレッド５０及び５２は、ＳＩＰプロキシサーバ２８ａがＳＩＰメッセージを次のサーバに制御パスに沿って送信することができるよりも速く、ＳＩＰメッセージを処理することができるようにしてもよい。この場合、処理モジュール４４は送信待ちのＳＩＰメッセージの待ち行列を作成するように構成されてもよい。この送信待ち行列も図４に示した技法６０並びに／又は図５及び６に示した技法を用いて優先度付けされるようにしてもよい。例えば、処理されたＳＩＰメッセージは、サービスタイプ、ネットワークエイジ、時間重み付け優先度値、ネットワーク利用度等に基づいて優先度付けされればよい。

本発明は種々の修正や代替の形式に対して影響を受けるものではあるが、特定の実施例が例示として図面に示されるとともに、ここに詳細に記載された。しかし、本発明は特定の形式の開示に限定されることを意図するものではない。逆に、本発明は特許請求の範囲で規定される発明の範囲のものとなる全ての変形例、同等物、及び代替例を包含するものである。

一実施例による代表的ＳＩＰメッセージのブロック図である。 一実施例によるＳＩＰメッセージを優先度付けするように構成された代表的ＩＭＳネットワークのブロック図である。 一実施例によるＳＩＰメッセージを優先度付けするように構成された代表的ＳＩＰプロキシサーバのブロック図である。 一実施例によるＳＩＰメッセージを優先度付けするための代表的技法を示すフローチャートである。 一実施例によるＳＩＰメッセージの優先度付けを決定するための代表的技法を示すフローチャートである。 一実施例によるＳＩＰメッセージの優先度付けを決定するための他の代表的技法を示すフローチャートである。

Claims (8)

1. ネットワーク内のＳＩＰメッセージを優先度付けする方法であって、
   該ネットワークにおける１以上の他のサーバから第１の順序でＳＩＰメッセージを受信するステップであって、受信した該ＳＩＰメッセージ（受信ＳＩＰメッセージ）各々が１以上のＱｏＳファクタを含む、ステップ、及び
   該受信ＳＩＰメッセージを該ＱｏＳファクタの１以上に基づいて第２の順序でスケジューリングするステップを備え、該スケジューリングするステップが
   該ＱｏＳファクタの１以上に基づいて該受信ＳＩＰメッセージの各々について優先度値を計算するステップ、
   計算された該優先度値を該ＳＩＰメッセージに関連付けるステップ、及び
   該優先度値に基づいて該受信ＳＩＰメッセージをスケジューリングするステップ
   を備え、
   さらに、
   該スケジューリングされたＳＩＰメッセージを該第２の順序で処理するステップ
   からなる方法。
   
2. 請求項１記載の方法において、前記受信ＳＩＰメッセージをスケジューリングするステップが、前記ＱｏＳファクタ及びタイムスタンプに基づいて該受信ＳＩＰメッセージをスケジューリングするステップからなる方法。
   
3. 請求項１記載の方法において、前記受信ＳＩＰメッセージ各々がサービスのタイプに関連し、前記受信ＳＩＰメッセージを送信のためにスケジューリングするためのＱｏＳファクタが、前記受信ＳＩＰメッセージに関連するサービスのタイプに対するＱｏＳ目標時間を含む方法。
   
4. 請求項１記載の方法において、第１のアプリケーションサーバに関連するＳＩＰメッセージに対する該優先度値が、第２のアプリケーションサーバに関連するＳＩＰメッセージに対する該優先度値と異なる方法。
   
5. 請求項１記載の方法であって、さらに、
   処理された前記ＳＩＰメッセージを前記ＱｏＳファクタに基づいて第３の順序にスケジューリングするステップ、及び
   前記処理されたＳＩＰメッセージを該第３の順序で他のサーバへ送信するステップ
   からなる方法。
   
6. サーバであって、
   ネットワークにおける１以上の他のサーバから第１の順序でＳＩＰメッセージを受信し、該受信したＳＩＰメッセージ（受信ＳＩＰメッセージ）各々が１以上のＱｏＳファクタを含み、
   該受信ＳＩＰメッセージを該ＱｏＳファクタの１以上に基づいて第２の順序でスケジューリングし、該受信ＳＩＰメッセージを第２の順序でスケジューリングすることが、該ＱｏＳファクタの１以上に基づいて該受信ＳＩＰメッセージの各々について優先度値を計算することからなり、計算された優先度値が該ＳＩＰメッセージに関連付けられており、及び
   該スケジューリングされたＳＩＰメッセージを該第２の順序で処理する
   ように構成されたＳＩＰスケジューリングモジュール
   からなるサーバ。
   
7. 請求項６記載のサーバであって、ＳＩＰプロキシサーバからなるサーバ。
   
8. 請求項６記載のサーバにおいて、前記受信ＳＩＰメッセージ各々に関連する優先度値に基づいて該受信ＳＩＰメッセージに記憶されたタイムスタンプを調整するように構成されたサーバ。

Images