(57)【要約】本発明は、分散型マルチメディアアプリケーション（１３０）を含む無線移動ネットワーク環境におけるモバイルコンピューティングの分野に関連する。詳しくは、本発明は、セッション記述プロトコルインプリメンテーション（ＳＤＰ、ＳＤＰｎｇ）及び拡張可能マークアップ言語（ＸＭＬ）の拡張に関連して、セッションレイヤプロトコル（ＳＩＰ）の新規な用途に基づいて、階層的なＱｏＳ契約仕様の適用及び使用を可能にするユーザプロファイルと端末の能力情報を定義する、モバイル機器上で動作する適応型の実時間サービス及びエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のためのサービス品質（ＱｏＳ）管理の分野に関する。  このため、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）を適用して、交渉可能な情報を導出し、これにより、モバイルアプリケーションをＱｏＳ違反に効率的且つタイムリに反応させることによって、一貫した、信頼できる、インクリメント的な手法で、２以上のエンドピア及び／又はミドルウェアのエンドツーエンド品質及び通信セッションのための能力に関する、前交渉、速やかな交渉、及び速やかな動的再交渉が可能となる。更に、本発明は、Ｅ２ＥＮＰのシグナリングパートをカプセル化する新規なＥ２ＥＮＰユーザエージェント（１２８）の概念と実現に関係する。Ｅ２ＥＮＰユーザエージェントは、交渉すべき情報を、マルチストリームマルチメディアアプリケーションが交渉された情報の特定の参照モデルに同意できるように、交換可能なフォーマットで表現し、参照モデルは、各ユーザの嗜好及びプロファイルに基づいて、ローカルリソース、ピアのリソース及びネットワークリソースを調整して、動的に有限状態マシンを構成するために用いられる。本発明の一実施形態では、採用されるＥ２ＥＮＰセッションレイヤプロトコルアプリケーションプログラミングインタフェース（１０１ａ〜ｅ）は、実際に使用されるセッションレイヤプロトコルとセッション記述プロトコルインプリメンテーションから独立している。
2006504363.tif 000002
【特許請求の範囲】
【請求項１】
モバイルネットワークに接続される移動通信セッションミドルウェア（１３０）に参加する少なくとも２つの登録されたエンドピア上で動作するマルチストリームマルチメディアアプリケーション（１３０）のためのアプリケーションプログラミングインタフェース（１０１ｂ）を提供し、
連結されたＥ２ＥＮＰフェーズの概念を用いて保証されたエンドツーエンド品質及びリソース能力を提供する通信システム（１２８）であって、当該通信システムは、
複数の代替の能力及びＱｏＳ契約の前交渉と、
リースされた前交渉された情報の管理と、
複数の代替の能力及び／又はＱｏＳ契約の交渉による上記エンドピアの間のセッション確立と、
エンドツーエンドの品質及び能力の動的な再交渉とを提供し、
上記交渉される情報は、上記マルチストリームマルチメディアアプリケーション（１３０）が該交渉された情報の特定の参照モデルに同意できるように、交換可能なフォーマットで表現され、該参照モデルは、各ユーザの嗜好及びプロファイルに基づいて、ローカルリソース、ピアのリソース及びネットワークリソースを調整して、動的に有限状態マシン（１０６）を構成するために用いられる通信システム。
【請求項２】
当該通信システム（１２８）は、内部的に、内部の処理とアプリケーションプログラミングインタフェース（１０１ａ〜ｅ）を調整する一組の有限状態マシン（１０６）に分解されることを特徴とする請求項１記載の通信システム。
【請求項３】
上記マルチストリームマルチメディアアプリケーション（１３０）及び／又は上記ミドルウェア（１３０）は、動的な構成のために、上記有限状態マシン（１０６）を用いることを特徴とする請求項２記載の通信システム。
【請求項４】
複数の同時に存在するユーザをサポートするよう設計されていることを特徴とする請求項１乃至３何れか１項記載の通信システム。
【請求項５】
電気通信ネットワーク内の２つのエンティティ間でセッションを確立するための通信システムにおいて、
ユニット（１２８）と、該ユニット（１２８）を管理するエンティティ（１０２）の間のインタフェース（ＩＦ１）を表す管理ＡＰＩ（１０１ａ）と、
上記ユニット（１２８）によって提供されたサービスを用いて、該ユニット（１２８）、ミドルウェア（１３０）及び／又はアプリケーション（１３０）の間のインタフェース（ＩＦ２）を表すＡＰＩ（１０１ｂ）と、
ユニット（１２８）とセッションレイヤプロトコルのユーザエージェント（１１０）との間のインタフェース（ＩＦ３）を表すジェネリックセッションレイヤプロトコルＡＰＩ（１０１ｃ）とを備える通信システム
【請求項６】
交渉オブジェクト識別子を管理するための２フェーズのＥ２ＥＮＰキャッシュ（１０４）であって、
各モバイル通信セッションを示すＥ２ＥＮＰセッション識別子と、
上記ユニット（１２８）の有限状態マシン（１０６）によって扱われる各サービスプロバイダを示すＥ２ＥＮＰセッション識別子と、
上記ユニット（１２８）によって提供されたサービスを用いて、全てのアプリケーション（１３０）及び／又はミドルウェア（１３０）によって扱われる各サービスユーザを示すＥ２ＥＮＰセッション識別子とを非持続的に保存及び読み出すことによって特定のアプリケーション（１３０）及び／又はミドルウェア（１３０）の識別スキームをＥ２ＥＮＰによって指定されたものから切り離すキャッシュ（１０４）を備える請求項１乃至５何れか１項記載の通信システム。
【請求項７】
上記ユニット（１２８）は、所定のＥ２ＥＮＰ前交渉又は交渉手続の実行の間、情報をプレキャッシングし、プレキャッシングされたデータは、一旦所定の手続が成功すると、後のＥ２ＥＮＰセッションの間、将来の参照のために、キャッシングされたままで残され、及び上記ユニット（１２８）は、新たなＥ２ＥＮＰ前交渉又は交渉手続の間にエンドピア間で既に（前）交渉されたデータへの参照として適用できる情報をキャッシングすることを特徴とする請求項１乃至６何れか１項記載の通信システム。
【請求項８】
実際に使用されるセッションレイヤプロトコル及びセッション記述プロトコルインプリメンテーションから独立しているＥ２ＥＮＰセッションレイヤプロトコルＡＰＩ（１０１ａ〜ｅ）を更に備える請求項１乃至７何れか１項記載の通信システム。
【請求項９】
Ｅ２ＥＮＰセッション記述をエンコードするために用いられ、ユニット（１２８）とファクトリインスタンス（１１４）の間のインタフェース（ＩＦ５）を表すファクトリＡＰＩ（１０１ｅ）を更に備える請求項１乃至８何れか１項記載の通信システム。
【請求項１０】
Ｅ２ＥＮＰセッション記述を復号するために必要な、ユニット（１２８）とパーサインスタンス（１１２）の間のインタフェース（ＩＦ４）を表すパーサＡＰＩ（１０１ｄ）を更に備える請求項１乃至９何れか１項記載の通信システム。
【請求項１１】
上記パーサインスタンス（１１２）とファクトリインスタンス（１１４）は、同じプロトコルを用いて構成できることを特徴とする請求項９又は１０記載の通信システム。
【請求項１２】
セッション記述プロトコル（ＳＤＰ）又はセッション記述プロトコル−次世代（ＳＤＰｎｇ）の拡張に関連するセッション開始プロトコル（ＳＩＰ）の新規な用途に基づいていることを特徴とする請求項１乃至１１何れか１項記載の通信システム。
【請求項１３】
上記セッションレイヤプロトコルと、上記セッション記述プロトコル（ＳＤＰ）又はセッション記述プロトコル−次世代（ＳＤＰｎｇ）は、それぞれ独自に構成可能であることを特徴とする請求項１２記載の通信システム。
【請求項１４】
モバイルネットワークに接続される移動通信セッションミドルウェア（１３０）に参加する少なくとも２つの登録されたエンドピア上で動作するマルチストリームマルチメディアアプリケーション（１３０）を、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）の拡張に基づいて、伝送品質の変化に動的に適応させる、保証されたエンドツーエンド品質及びリソース能力を提供する交渉方法において、
複数の代替の能力及びＱｏＳ契約の前交渉を行うステップと、
リースされた前交渉された情報を管理するステップと、
複数の代替の能力及び／又はＱｏＳ契約の交渉による上記エンドピアの間のセッションを確立し、端末及びネットワークリソース予約の調整を行うステップと、
結合されたＥ２ＥＮＰフェーズの概念を用いて、第１の、エンドツーエンドの品質及び能力の動的な再交渉を行うステップとを有し、
更に、当該交渉方法は、
上記マルチストリームマルチメディアアプリケーション（１３０）が該交渉された情報の特定の参照モデルに同意できるように、交換可能なフォーマットで表現するステップを有し、該参照モデルは、各ユーザの嗜好及びプロファイルに基づいて、ローカルリソース、ピアのリソース及びネットワークリソースを調整して、動的に有限状態マシン（１０６）を構成するために用いられる交渉方法。
【請求項１５】
上記リソース予約を調整する処理は、ネットワークＱｏＳ及び安全確立を、セッションレイヤプロトコルによって開始され、セッション記述プロトコルインプリメンテーションによって記述されるセッションの必須条件とするマルチフェーズの呼出設定メカニズムに基づいて実行され、ネットワークリソース予約メカニズムは、セッション開始前に準備され、ユニット（２１８）によって、ミドルウェア（１３０）の登録されたクライアント側に呼び出され、それぞれ所定の交換処理の到着を示し、又は所定の交換処理の結果を確認する指示（Ｉｎｄ）及び確認（Ｃｆｍ）プリミティブは、Ｅ２ＥＮＰの統合された一部であり、該ユニット（１２８）及びその対応する交渉処理を用いて、エンティティによって有効にされたピアの能力を指定するか又は有効にされたＱｏＳ契約を定義するＥ２ＥＮＰ「ｑｏｓｄｅｆ」セクション（１３００）にマッピングされることを特徴とする請求項１４記載の交渉方法。
【請求項１６】
「経済原理」に基づいて、異なるピア間の予約処理を強制的に同期させることを特徴とする請求項１４又は１５記載の交渉方法。
【請求項１７】
オファー側のエンドピアによるネットワークリソース予約が行われていない場合、アンサ側として動作する他のエンドピアのユニット（１２８）は、オファー側によって生成される必須条件を調べることによってこれを検出し、これに応じて、アンサ側がリソース予約調整をトランスペアレントに扱うことができるようにすることを特徴とする請求項１４乃至１６何れか１項記載の交渉方法。
【請求項１８】
エンドツーエンドの予約及びセグメント化された予約の両方を可能とし、上記ネットワークリソース予約は、セッション確立上のコスト及び／又は主な影響なしで、ローカルに実行されることを特徴とする請求項１４乃至１７何れか１項記載の交渉方法。
【請求項１９】
マルチストリームマルチメディアアプリケーション（１３０）又はミドルウェア（１３０）がネットワークリソースの「前予約」の実行を望む場合、Ｅ２ＥＮＰシグナリングは、上記アプリケーション（１３０）又はミドルウェア（１３０）にそれぞれ正しいタイミングを与え、全ての側のリソース予約がいつ実現されたかを知らせることを特徴とする請求項１４乃至１８何れか１項記載の交渉方法。
【請求項２０】
適用された前交渉と交渉プリミティブによって受け渡され、Ｅ２ＥＮＰ情報をピギーバックするために用いられる基底にあるセッションレイヤプロトコルによって用いられる特定の統語構造にマッピングされる異なるＥ２ＥＮＰユーザを特定するＥ２ＥＮＰアドレス（６００）を含むＥ２ＥＮＰ統語構造は、下部でユニット（１２８）によって用いられる上記セッションレイヤプロトコル及び／又はそれぞれのトランスポートプロトコルから独立していることを特徴とする請求項１４乃至１９何れか１項記載の交渉方法。
【請求項２１】
２つのピアが同時にＥ２ＥＮＰフェーズを開始した場合に適用される請求項１４乃至２０何れか１項記載の交渉方法のために用いられる競合解決方法であって、
Ｅ２ＥＮＰ  ＵＡ（１２８）は、オファー側によって送られたセッション識別子だけではなく、その後のあらゆるセッションレイヤプロトコルメッセージ内に該セッション識別子の代替として、そのハッシュも含んでおり、該ハッシュは、Ｅ２ＥＮＰ  ＵＡ（１２８）がアカウントに有効である演算ユニットのＩＰアドレスと、交渉又は前交渉フェーズが開始されるときに常に適用されるタイムスタンプとを含むことを特徴とする競合解決方法。
【請求項２２】
２つのピアが既にマルチメディアセッションに関わっていない場合、該各ピアは、自らが生成したハッシュを相手側から受信したハッシュと比較し、最大値を有するピアをオファー側として自動的に選択して前交渉又は交渉フェーズを継続し、他方のピアを自動的にアンサ側モードに移行させることを特徴とする請求項２１記載の競合解決方法。
【請求項２３】
２つのピアが既にマルチメディアセッションに関わっている場合、要求が拒絶されたピアは、要求が受理されたピアが交渉手続を完了した後に、計画されていない再交渉手続を適用することを特徴とする請求項２１記載の競合解決方法。
【請求項２４】
請求項１乃至１３何れか１項記載の通信システム（１２８）を備える通信ネットワーク。
【請求項２５】
無線ネットワーク環境内の移動端末上で動作し、請求項１乃至１３何れか１項記載の通信システム（１２８）をインプリメントするコンピュータソフトウェアプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散型マルチメディアアプリケーション及びシステムを含む移動無線ネットワーク環境における分配型モバイルコンピューティングに関する。詳しくは、本発明は、動的な無線インターネットプロトコル（ＩＰ）ネットワークにおいて、異なるアクセス技術をサポートする固定機器及びモバイル機器上で動作する適応型の実時間ストリーミングサービスの品質交渉及びセッション確立に関し、したがって、マルチメディアミドルウェア及びリソース予約メカニズムに関連する研究開発上の問題に関する。
【背景技術】
【０００２】
分散型システムが直面する主な問題は、エンドシステムにおいて及びネットワーク内で、不安定な環境条件の下、リソースとどのように連携するかという問題である。実際、モバイルユーザは、ネットワークインフラストラクチャによってＱｏＳ契約がサポートされない好ましくない状況に頻繁に遭遇すると予想される。このような状況は、「ＱｏＳ違反」と呼ばれる、例えば、無線リンク品質の低下、水平及び／又は垂直のハンドオーバ、移動端末リソースの制約等に起因して生じる。バックボーンにおいて、適切なリソースが十分に提供されいる場合、ＱｏＳ違反は、アクセスネットワーク内の特に無線リンクの箇所におけるハンドオーバに起因して生じることが多いと予想される。
【０００３】
更に、複数のピアと交換される複数のメディアストリームの情報を同時に取り扱うモバイルマルチメディアアプリケーションは、特に上述した不安定な環境条件の観点から、有効且つ効率的に交渉を行い、ＱｏＳ要求を処理する能力を必要とする。
【０００４】
不安定な環境条件に対処する一手法として、モバイルユーザのアプリケーションをＱｏＳ違反に効率的且つタイムリーに対応させるという手法がある。実際、ピアは、異なる抽象化レベルにおいて、オフラインで様々な代替的なＱｏＳ契約を交渉でき、これにより、接続が確立している間及びＱｏＳ違反が生じたときはいつでも、ピア間で、どうすれば最も効率的に変化した条件に対応できるかに関する合意をタイムリーに実現することができる。
【０００５】
従来の技術の説明
エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）は、既に、欧州特許出願第０１１２２３６６．６号に開示されている。本発明は、この欧州特許出願に開示されいている技術を発展させるものであり、この特許文献の開示内容は、引用により本願に援用される。
【０００６】
ＱｏＳ及び能力交渉プロトコルの概念について説明する文献のリストを（アルファベット順に）以下に示す。
【０００７】
【表１Ａ】
2006504363.tif 000003
【０００８】
【表１Ｂ】
2006504363.tif 000004
【０００９】
［Ｃａｍ１］は、ネットワークＱｏＳ及び安全確立をセッション開始プロトコル（ＳＩＰ）によって開始され、セッション記述プロトコル（ＳＤＰ）によって説明されるセッションの必須条件とするマルチフェーズの呼出設定メカニズムを提案する。ネットワークリソースは、既存のネットワークリソース予約メカニズム（例えば、ＲＳＶＰ）を用いて、セッションが開始される前に予約される。
【００１０】
［Ｋｌｙ１］は、メディア処理能力を表すメディア特徴セット（media feature sets）を表現するためのフォーマットを提案する。更に、特徴セットに適合するアルゴリズムが提案されている。このアルゴリズムは、送信側と受信側の能力が互換性を有しているか否かを判定するために用いることもできる。更に、［Ｋｌｙ２］には、コンポジットメディア特徴セットを表す特徴表現のハッシュを用いる簡略化されたフォーマットが開示されている。
【００１１】
［Ｒｏｓ２］には、ＳＤＰによる一対一の能力交渉のための完全なモデルが開示されている。但し、このモデルは、ＳＤＰの階層構造が平坦であるため、相互参照情報及びメディアストリームのグループ化に関する情報の定義に関する問題が生じやすい。
【００１２】
［Ｋｕｔ１］は、複数の参加者によるマルチメディア会議シナリオにおけるセッション記述及びエンドポイント能力交渉のためのフレームワークに関する要求のセットを開示している。ここでは、ユーザの好み、システム能力又は他の制約条件に応じて、会議のための異なる構成を選択することができる。ここでは、ピア内の交渉処理の必要性が示されているが、可能な構成の共通の組を判定し、情報交換のために用いる共通の構成の１つを選択する手法は開示されていない。この能力交渉を用いて、エンドシステムの能力及び潜在的な参加者であるユーザの好みに互換性がある有効なセッション記述を獲得することができる。異なる会議の種類に応じて、異なる交渉ポリシを用いてもよい。また、ここでは、セッション設定に関連するネットワークリソース予約の必要性も指摘されている。更に、ここでは、能力を記述するために、プロトコルではなく、交渉言語を用いることが提案されている。したがって、［Ｋｕｔ１］で提案されるソリューションは、ＱｏＳ構成の一般的なセットを決定するための交渉プロトコルについても、ローカル、ピア及びネットワークリソースの予約を統合についても考慮していない。
【００１３】
以下、［Ｋｕｔ２］と呼ぶこのＩＥＴＦドラフトの最新のバージョンは、オーディオコーデック及びリアルタイムプロトコル（ＲＴＰ）プロファイルに関する詳細なＸＭＬスキーマの仕様及びプロトタイプを提供する。
【００１４】
［Ｂｏｓ１］には、エンドピアの交渉されたＱｏＳ情報に関する最終的な決定には、幾つかのミドルウェア及びサービスが深く関わっているという仮定に基づく、エンドツーエンドのユーザによって知覚されるＱｏＳ交渉が開示されている。ここに開示されている決定は、幾つかの標準の「契約タイプ」に基づく。ここでは、シグナリングとデータパスは、ネットワーク内で別々の経路で通信されることがあるとしながら、交渉パスの途中のある、通常はデータパスに関係しないミドルウェアが交渉に影響を及ぼしてもよいとしている。このプロトコルモデルを用いた場合、ネットワークは、トランスペアレントではなくなる。［Ｂｏｓ１］に基づく交渉処理は、プロトコルのモジュール性と、ＱｏＳに関する情報の一貫性とを考慮することなく、幾つかの非ＱｏＳ情報（例えば、機密保護、ネットワークアドミタンス等）がインタリーブされた１つのショットにおいて実行される。［Ｂｏｓ１］のモデルでは、交渉には、プッシュモードしか用いることができないため、アプリケーション及びサービスが制限される。適応化パスは、劣化するのみであり、固定されている。
【００１５】
論文［Ｍａｎ１］、［Ｍａｎ２］及び［Ｃａｍ２］では、メディアストリームのグループ化の可能性が検討されている。但し、これらの文献では、グループ化の基準、再帰的なグループ構築の可能性（複数のグループを含むグループ）、グループ化が可能な実時間、擬似実時間、非実時間情報メディアストリームの処理等については検討されていない。更に、［Ｍａｎ１］と［Ｍａｎ２］は、交渉ステップを定義し、これらの交渉ステップは、１ショットで実行しても複数のショットで実行してもよいが、独立した交渉フェーズとして行うことはできない。このため、交渉フェーズ及びその後における交渉されたＱｏＳ情報の一貫性に対する要求は満たされない。［Ｍａｎ１］は、Ｅ２ＥＮＰのコアとなる概念を開示している。また、「経済原理（Economy Principle）」アプリケーションの衝突に関する処理は、考慮されていない。更に、［Ｍａｎ１］及び［Ｍａｎ２］は、ＱｏＳ適応化のための適応化パスの設定及び管理の可能性について説明しており、これらは、第３のコンポーネントであるＱｏＳブローカによって制御される。但し、エンドパーティ自身が自らの交渉を実行し、制御する可能性については検討されていない。
【００１６】
今日の適応型のアプリケーションミドルウェア（例えば、ＱｏＳブローカ）は、ＱｏＳ前交渉、ＱｏＳ交渉、ＱｏＳ再交渉、資源予約及び／又は解除の調整を行うとともに、これらの機能を実現するシグナリングプロトコルの種類をマスクし、技術から独立したアプリケーションプログラミングインタフェース（ＡＰＩ）を提供するコンポーネントを備えていない。すなわち、適応型のマルチストリームマルチメディアアプリケーション及び／又はミドルウェアは、Ｈ．３２３、セッション開始プロトコル（ＳＩＰ）及び／又はセッション記述プロトコル（ＳＤＰ、将来的には、［Ｋｕｔ２］に説明されているＳＤＰｎｇ）等のプロトコルに応じて直接コード化する必要がある。更に、ＳＩＰ及び／又はＳＤＰベースのアプリケーション又はミドルウェアは、ＳＤＰデータの解析を直接実行し、ＳＤＰデータにおける、以前に交換されたバージョンからの変化を調べることによって、行うべき動作を推定する。
【００１７】
他の問題として、適応型のアプリケーション及び／又はミドルウェア（例えば、ＱｏＳブローカ）は、交渉すべき情報（例えば、能力、アプリケーションレベルＱｏＳ契約、ネットワークレベルＱｏＳ契約、ストリームレベル適応化パス及びストリームグループレベル適応化パス）を交換可能なフォーマットで表現できないという問題がある。異種のアプリケーション及び／又はミドルウェアが参照モデルに容易に同意し、続いて、この参照モデルを用いて、アプリケーション及び／又はミドルウェアが動的に自ら構成し、様々なピアにおいて用いられている異種のアプリケーション及びミドルウェアの多様性に応じて、各ユーザの好みとプロファイル及び各システム及びネットワークプロバイダのポリシに基づいて、ローカルリソース、ピアのリソース及びネットワークリソースを調整する必要がある。
【００１８】
欧州特許出願第０１１２２３６６．６号には、総合的なＥ２ＥＮＰ概念、その要求及び可能なインプリメンテーションの発想が開示されているが、具体的なインプリメンテーションについては詳しく述べられていない。如何なる前交渉された情報も時間内には、達成されない。
【００１９】
［Ｋｕｔ２］に開示されているようなＳＤＰｎｇの現在の形式は、モジュール構造を有しているが、Ｅ２ＥＮＰの側面は考慮されておらず、異なるＳＩＰメッセージ（又は他のプロトコルメッセージ）に亘ってモジュール方式で用いることができない。ＳＤＰｎｇに基づく能力交渉は、［Ｒｏｓ２］に開示されているＳＤＰオファー／アンサモデルを使用するが、ここでは、Ｅ２ＥＮＰで提案されている複雑なマルチフェーズの交渉処理は、明らかに考慮されていない。
【００２０】
欧州特許出願第０１１２２３６６．６号及びＳＤＰｎｇの何れによっても、ユーザプロファイル情報を総合的なＱｏＳ交渉処理のための入力とみなすことができる処理は実現されない。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
上述の課題に鑑み、本発明の主な目的は、適応型の実時間サービスとマルチメディアアプリケーションのためのリソース予約メカニズムと組み合わせて、能力及びＱｏＳ交渉及びセッション確立をサポートする交渉方法及びソフトウェアアーキテクチャを提供することである。
【課題を解決するための手段】
【００２２】
この目的は、独立請求項の特徴によって達成される。好ましい特徴は、従属請求項によって定義される。本発明の更なる目的及び効果は、以下の詳細な説明によって明らかになる。
【００２３】
本発明は、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）すなわち、［ＲｅｑＳｐｅｃ］に開示されている、エンドツーエンドシグナリングＥ２ＥＮＰの処理をカプセル化するソフトウェアモジュールのための、基本的に新規なユーザエージェント（ＵＡ）の概念とその実現を目的とする。本発明は、ユーザプロファイルと端末の能力情報を定義するために有効に適用でき、階層的なＱｏＳ契約仕様（例えば、関連するメディアストリームのためのＱｏＳ契約の異なる組に亘って相関を強制する）を適用し、これを用いることによって、交渉可能な情報を引き出すことができる。この概念のインプリメンテーション例として、本発明は、エンドツーエンドＱｏＳ交渉プロトコル（Ｅ２ＥＮＰ）概念をインプリメントするために、拡張可能マークアップ言語（ＸＭＬ）に基づいて、セッション記述プロトコル−次世代（ＳＤＰｎｇ）仕様の拡張に関連して、インターネットエンジニアリングタスクフォース（Internet Engineering Task Force：ＩＥＴＦ）によって標準化されているセッション開始プロトコル（ＳＩＰ）の新規な用途を開示する。詳しくは、ここに提案するモデルは、ユーザプロファイルと端末の能力情報を定義することによってＳＤＰｎｇ交渉メカニズムを拡張し、階層的なＱｏＳ契約仕様の適用及び使用を実現する。
【００２４】
このため、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）を適用して、交渉可能な情報を導出し、これにより、モバイルアプリケーションをＱｏＳ違反に効率的且つタイムリに反応させることによって、一貫した、信頼できる、インクリメント的な手法で、２以上のエンドピア及び／又はミドルウェアのエンドツーエンド品質及び通信セッションのための能力に関する、前交渉、速やかな交渉、及び速やかな動的再交渉が可能となる。更に、本発明は、Ｅ２ＥＮＰのシグナリングパートをカプセル化する新規なＥ２ＥＮＰユーザエージェントの概念と実現に関係する。Ｅ２ＥＮＰユーザエージェントは、交渉すべき情報を、マルチストリームマルチメディアアプリケーションが交渉された情報の特定の参照モデルに同意できるように、交換可能なフォーマットで表現し、参照モデルは、各ユーザの嗜好及びプロファイルに基づいて、ローカルリソース、ピアのリソース及びネットワークリソースを調整して、動的に有限状態マシンを構成するために用いられる。
【００２５】
本発明により、パーサ及びファクトリインプリメンテーションにより、内部の（アプリケーション及び／又はミドルウェア固有の）表現と外部（ＳＩＰユーザエージェント固有の）表現との間で、交換可能なフォーマットの対話が実現される。また、これらのソフトウェアコンポーネントは、基底にあるキャリアプロトコルエージェント、Ｅ２ＥＮＰユーザエージェント及び各アプリケーションミドルウェアの特定の必要性に基づいて構成可能である。これに関連して、適用された交渉処理及び副処理の特定のＥ２ＥＮＰユーザエージェントセッション識別と各アプリケーションミドルウェアセッション識別は、前交渉、交渉及び／又は再交渉セッションをユニークに特定できるように、互いにユニークにマッピングされ、キャッシュされる。この結果、パーサ、ファクトリ及びキャッシュは、各Ｅ２ＥＮＰユーザエージェントのインプリメンテーションに関連付けられる。なお、これらの４つのソフトウェアコンポーネント、すなわち、パーサ、ファクトリ、キャッシュ及びＥ２ＥＮＰユーザエージェント、並びに適用されたキャリアプロトコルのユーザエージェントの構成は、それぞれ、採用されるアプリケーションミドルウェアコンポーネントの必要性に応じたアプリケーション固有のタスクである。
【発明を実施するための最良の形態】
【００２６】
本発明の一実施形態においては、Ｅ２ＥＮＰ  ＵＡ１２８は、Ｗｉｎ３２とリナックスのプラットフォームをサポートする。本発明のアーキテクチャ及びそのソリューションは、品質、ロバスト性、保守可能性、拡張性、柔軟性及び効率を向上させることを目的とする。
・ここで言う品質は、既に開発の間におけるシステムの検査及び検証の容易性を含む。ロバスト性とは、エラーが存在する状況でも安定して利用可能な状態を保つシステムの能力を意味する。何れの目的も、システムの有用性と許容性に直接影響する。
・保守可能性と拡張性は、後のフェーズ（誤り訂正と拡張の両方に関する）におけるシステムの全てのコストに関連する。これらのコストは、最小化すべきである。
・また、柔軟性は、可能な限りコスト効率がよい変更を行うべきであるという課題に関連する。
・効率性は、リソース（メモリとプロセッサに関する）の使用量の最小化に関連する。
【００２７】
このアーキテクチャについて、以下のような基本的な概念的且つ技術的な要求を導出することができる。
・適切に選択され、よく定義された責任及び特徴による設計コンポーネントの定義。
・変化のによる影響を小さくする設計コンポーネント間の弱い依存関係（疎結合：loose coupling）。
・特に適用されたランダムアクセスメモリ（ＲＡＭ）に関する最小のリソース消費。
・インタフェースとインプリメンテーションとの間の厳密な分離（インプリメンテーションの変化は、インタフェースに影響しないものとする）。
・制約の定義。但し、この定義が実現概念を簡素化する場合、制約及びそれらの効果を利害関係者と交渉する必要がある。
【００２８】
図１に示すＥ２ＥＮＰ  ＵＡ１２８は、以下の５つのＡＰＩを通して、環境と通信を行うソフトウェアコンポーネントとして設計される。
・Ｅ２ＥＮＰ管理ＡＰＩ１０１ａ（ＩＦ１）：このＡＰＩは、Ｅ２ＥＮＰ  ＵＡ１２８と、これを管理するエンティティ１０２との間のインタフェースを表す。管理とは、構成、監視及び制御を含む。
・Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂ（ＩＦ２）：このＡＰＩは、Ｅ２ＥＮＰ  ＵＡ１２８と、Ｅ２ＥＮＰ  ＵＡ１２８によって提供されたサービスを用いるアプリケーション１３０又はミドルウェアとの間のインタフェースを表す。このＡＰＩを通して交換された情報は、オブジェクト構造として又はＸＭＬベースのドキュメントとしてモデル化でき、これにより、Ｅ２ＥＮＰ  ＵＡ１２８上のアプリケーション１３０又はミドルウェア１３０によって解釈される。
・ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ（ＩＦ３）：このＡＰＩは、Ｅ２ＥＮＰ  ＵＡ１２８とＥ２ＥＮＰ−仕様を実現するために用いられるセッションレイヤプロトコルとの間のインタフェースを表す。このＡＰＩの名称は、［Ｒｏｓ１］に開示されているセッション開始プロトコル（ＳＩＰ）を参照セッションレイヤプロトコルとして用いることを明確に表している。なお、このＡＰＩは、僅かな変更により、将来の設計基準に容易に般化でき、Ｅ２ＥＮＰ  ＵＡのＳＩＰに対する依存性を排除できる。但し、この設計を用いることによってＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ（ＩＦ３）の完全なＪａｖａ（登録商標）リモートメソッド呼出（Remote Method Invocation：ＲＭＩ）インプリメンテーションを実現することができる。
・パーサＡＰＩ１０１ｄ（ＩＦ４）：このＡＰＩは、Ｅ２ＥＮＰ  ＵＡ１２８と、Ｅ２ＥＮＰセッション記述を復号するために用いられるパーサインプリメンテーション１１２との間のインタフェースを表す。
・ファクトリＡＰＩ１０１ｅ（ＩＦ５）：このＡＰＩは、Ｅ２ＥＮＰ  ＵＡ１２８と、Ｅ２ＥＮＰセッション記述を符号化するために用いられるファクトリツール１１４との間のインタフェースを表す。
【００２９】
Ｅ２ＥＮＰ  ＵＡ１２８は、内部的には、上述のインタフェースに関連する手続及びそれらの相互関係を調整する異なる有限状態マシン１０６（ＦＳＭ）で構成される。詳しくは、Ｅ２ＥＮＰ  ＵＡ１２８は、Ｅ２ＥＮＰの開始、（前）交渉及び／又はセッション確立及びこのような手続への応答をそれぞれ個別且つ同時に取り扱うためにクライアントＦＳＭ１０６とサーバＦＳＭ１０６とを特徴付ける必要がある。これは、インタフェース１０１ｃ（ＩＦ３）のプリミティブにインタフェース１０１ｂ（ＩＦ２）のプリミティブをマッピングし、及びこの逆のマッピングを行うことを意味する。このプリミティブのマッピングは、オブジェクトのマッピングと、オブジェクト識別子のマッピングの両方を含む。マッピングされたオブジェクト及び識別子は、Ｅ２ＥＮＰ  ＵＡ１２８及び／又はＩＦ２上のアプリケーション１３０において、それぞれのキャッシュ１０４に保存される。
【００３０】
このマッピング処理の間、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、Ｅ２ＥＮＰセッション記述の復号及び符号化を取り扱うために、インタフェース１０１ｄ（ＩＦ４）とインタフェース１０１ｅ（ＩＦ５）のそれぞれにアクセスできなくてはならない。
【００３１】
パーサ及びファクトリインプリメンテーション１１２、１１４は、それぞれ、Ｅ２ＥＮＰ概念を実現するために不可欠なエンティティであるが、様々な手法により（ＳＤＰ、ＳＤＰｎｇ、ＳＤＰｎｇダイアレクト又は選択されたこの他のセッション記述言語に基づいて）、独立したソフトウェアコンポーネントとして設計される。
【００３２】
以下のサブセクションでは、システムの基本的な問題領域（problem domains）及びこれがＥ２ＥＮＰ  ＵＡ１２８においてどのように解決されるかを説明する。以下では、各問題領域について、個別に及びシステムに亘って議論する。また、ある問題領域が他の問題領域に関連する場合、又は問題領域の一部を他のセクションにおいてより詳細に説明する場合、他の問題領域について言及することもある。
【００３３】
Ｅ２ＥＮＰ  ＵＡ１２８は、オブジェクト指向パラダイムに基づいて設計され、ここでは、このような設計に基づくＪａｖａベースのプロトタイプを説明する。このプロトタイプにより、（ＩＦ４を介して）様々な種類のＸＭＬ解析ツール及び（ＩＦ３を介して）様々なセッションレベルのプロトコルを用いてＥ２ＥＮＰプリミティブをトランスポートすることができる。ここに説明するＥ２ＥＮＰ  ＵＡ設計に基づくプロトタイプは、［Ｒｏｓ１］においてセッションレイヤプロトコルとして開示されているＳＩＰを用いる。Ｅ２ＥＮＰ  ＵＡ設計により、ＩＦ３の抽象的な性質のために、様々な種類のＳＩＰインプリメンテーションがサポートされる。
【００３４】
本発明では、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６とＳＩＰ  ＵＡジェネリックＡＰＩ（ＩＦ３）の両方が、ＳＩＰをサポートするよう明示的に設計される。将来の設計においては、ＩＦ３の抽象度を更に高めることにより、これらの依存関係をなくすことができると考えられる。また、Ｅ２ＥＮＰ  ＵＡ１２８は、Ｅ２ＥＮＰ  ＵＡサービスの複数のインスタンスを用いて複数のアプリケーション１３０の複数のユーザを同時にサポートできる。
【００３５】
Ｅ２ＥＮＰ  ＵＡ１２８は、識別子（ＩＤ）、記述オブジェクト（オブジェクトグラフ又はＸＭＬ等のオブジェクトグラフの形式的記述）及びイベントオブジェクトの３つの種類のオブジェクトカテゴリをサポートする。これらのカテゴリは、ＩＦ２、ＩＦ３、ＩＦ４及びＩＦ５を介して、エージェントに渡される双方向のオブジェクトに対応している。
・セッション記述オブジェクトをユニークに特定するためには、ＩＤが必要である。識別子の種類は２つあり、これらもオブジェクトである。
【００３６】
・Ｅ２ＥＮＰの内部のオブジェクトＩＤは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６内で処理されたオブジェクトに対応する。
【００３７】
・アプリケーション１３０によって交渉イベントを処理するために用いられる各Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６オブジェクトを指示するアプリケーションＩＤ
・セッション記述オブジェクトは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ処理によって用いられるオブジェクトグラフであってもよく、交渉処理においてパーサインプリメンテーション１１２、ファクトリインプリメンテーション１１４、Ｅ２ＥＮＰ  ＵＡ１２８によって用いられる外部の記述であってもよい。全てのセッション記述オブジェクトは、これらを用いるアプリケーション１３０において（ＩＦ２上で）持続的に保存される。保存されたオブジェクトの管理（記述のリース、リースされた記述の更新等）は、アプリケーション固有のタスクである。
・イベントオブジェクトは、適応化シーケンスをトリガすることによってＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６機能に影響を与えるアプリケーション交渉イベントに対応する。
【００３８】
ＩＤ、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭオブジェクトグラフ及びイベントオブジェクトは、Ｊａｖａオブジェクトである。外部のプロトコル表現は、ＳＤＰ、ＳＤＰｎｇ、ＳＤＰｎｇダイアレクト又は選択されたこの他のセッション記述言語の何れであってもよい。インタフェースＩＦ２を通過するＪａｖａオブジェクトのインプリメンテーションは、ＩＦ２のインタフェース定義に依存する。インタフェースＩＦ４、ＩＦ５を通過するオブジェクトは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６オブジェクト表現又は外部のプロトコル表現の何れであってもよい。ＩＦ３を通過するオブジェクトは、外部のプロトコル表現である。ＳＩＰ代理ＲＭＩインプリメンテーションとの互換性を保つために、ＩＦ３、ＩＦ４及びＩＦ５を通過するセッション記述オブジェクトの全ての外部の表現は、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅをインプリメントする必要がある。
【００３９】
ＩＦ２、ＩＦ３、ＩＦ４及びＩＦ５を介して渡されるセッション記述オブジェクトの内部表現は、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔのタイプを有し、Ｅ２ＥＮＰ  ＵＡ１２８、パーサ１１２及びファクトリ１１４によって期待されるタイプに含まれる必要がある。この要求は、ジェネリックＡＰＩを利用してＳＩＰ  ＵＡ１１０と、パーサ１１２及びファクトリ１１４のインプリメンテーションのモジュール性を維持するために必要である。
【００４０】
以下のセクションでは、パーサ１１２とファクトリ１１４の適用されたインプリメンテーションの概観を示す。
【００４１】
交渉処理は、ネットワークによって相互接続された少なくとも２つのエンティティを含むため、ネットワーク及び背景を介して、システム内部表現からトランスポート表現へのマッピング機能を実現する必要がある。このマッピングを提供するメカニズムは、パーサＡＰＩ１０１ｄ（以下、単にパーサ１１２という。）及びファクトリＡＰＩ１０１ｅ（以下、ファクトリ１１４という。）と呼ばれる。ここで、パーサ１１２は、ネットワーク表現で符号化されたオブジェクトを入力として受け取り、オブジェクトのシステム内部表現を生成する。一方、ファクトリ１１４は、所定のシステムの内部表現のためのネットワーク表現を生成する。
【００４２】
このパーサＡＰＩ１０１ｄ、ファクトリＡＰＩ１０１ｅ、及びこれらによって定義される機能の必要性は、このシステム内部表現がシステム内部表現として適切であるという事実から生じる。更に、これらのコンポーネントをシステムに導入することにより、より上位のアプリケーションレイヤが下位のトランスポート指向レイヤから切り離される。結果として、実際に使用されるトランスポートプロトコルは上位のアプリケーションレイヤには全く関与せず、理想的には、プラガブル（pluggable）であるべきである。
【００４３】
トランスポート統語構造として拡張可能マークアップ言語（ＸＭＬ）を使用することは、ＸＭＬが工業規格として広く採用されており、及び外部の機能（ＳＤＰｎｇライブラリとプロファイル）の組み込みが可能であるという利点を有する。ＸＭＬの他の利点は、簡単な拡張性である。
【００４４】
上述したように、異なるキャリアプロトコルを使用するためには、プロトコルと同様に、パーサ１１２とファクトリ１１４が構成可能である必要があり、これは、プロトコルが実行時に構成可能である場合、パーサ１１２及びファクトリ１１４もシステム実行中に変更する必要が生じる場合があることを意味する。実際のインプリメンテーションは、基底にある特定のキャリアプロトコルに依存するため、上述した必要性は、抽象的なインタフェースの使用を含意する。
【００４５】
異なるキャリアプロトコルのための具体的なファクトリ１１４のインプリメンテーションは、それぞれ異なる結果を生じる。例えば、ＲＭＩファクトリは、単にダミーのインプリメンテーションであってもよい。このため、単にＪａｖａリモートメソッド呼出（ＲＭＩ）を用いて、ネットワーク接続を介して、例えばオブジェクト等のＪａｖａオブジェクトを「そのまま」直接転送することができる。なお、ＳＩＰがキャリアプロトコルとして用いられる場合、ネットワークを介して送信すべき外部の表現（より正確には、プロトコルデータユニット又はＰＩＵ）を生成する必要がある。ここでは、以下に限定されるものではないが、ＳＤＰと同様の幾つかの専用テキストフォーマットを用いてもよく、又は、例えば、ＳＤＰｎｇ等のＸＭＬに基づくより構造化された手法を用いてもよい。
【００４６】
パーサＡＰＩ１０１ｄとファクトリＡＰＩ１０１ｅのためのＡＰＩの定義は、Ｅ２ＥＮＰ  ＵＡ１２８及びパーサ１１２、並びにファクトリ１１４の間の疎結合をサポートするために、タイプ化されない。トランスポート表現は、上述のように、単に、生来的にタイプ化されないｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースを用いてインプリメントされる。システム内部表現は、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔとして表現されるように選択される。パーサ１１２とファクトリ１１４の実際のインプリメンテーションと、Ｅ２ＥＮＰ  ＵＡ１２８において用いられるオブジェクト表現との間のマッチングは、構成によって確立する必要がある。
【００４７】
このメカニズムは、以下の２つのソフトウェアコンポーネントによってインプリメントされる。
・パーサＡＰＩ１０１ｄ：このＡＰＩのプリミティブは、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントするあらゆるオブジェクトをパラメータとして受け入れる必要がある。解析処理の結果、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔとして抽象的にタイプ化されるＩＦ２に基づくオブジェクト表現が生成される。
・ファクトリＡＰＩ１０１ｅ：このＡＰＩのプリミティブは、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔとして抽象的にタイプ化されるＩＦ２に基づくあらゆるオブジェクト表現をパラメータとして受け入れ、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースに従う表現を生成する必要がある。
【００４８】
更に、構成可能性を実現するために、パーサ１１２及びファクトリ１１４インスタンスを生成するための「ファクトリ設計パターン」を用いることもソリューションの１つである。このために、ファクトリメソッドは、トランスポートプロトコルによってパラメータ化される（異なるパーサ１１２／ファクトリ１１４インプリメンテーションの弁別的特徴）。異なるキャリアプロトコルのための動的なサポートが必要である場合、ファクトリクラスは、新たなプロトコルのための登録手続を提供する必要がある。
【００４９】
次のセクションでは、ＳＩＰ代理（SIP surrogates）の使用について説明する。
【００５０】
適用されたＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ（ＩＦ３）は、このようなＡＰＩをサポートするＳＩＰ  ＵＡインプリメンテーションを必要とする。同様に、パーサＡＰＩ１０１ｄ（ＩＦ４）とファクトリＡＰＩ１０１ｅ（Ｆ５）は、それぞれＵＡインプリメンテーション１１０に互換性を有するパーサ及びファクトリのインプリメンテーションの利用可能性を前提としている。Ｅ２ＥＮＰモデルの検証及び速やかなプロトタイプ化を実現するために、ＩＦ３、ＩＦ４及びＩＦ５は、実際のＳＩＰ  ＵＡインプリメンテーション及び互換性があるパーサ１１２及びファクトリ１１４インプリメンテーションの代理を実験的な目的のための簡易な代替手段として用いることができるように設計されている。
【００５１】
Ｅ２ＥＮＰ  ＵＡ１２８を検査及び／又は更新するためにＳＩＰ  ＵＡ１１０について旧来のインプリメンテーション（既に提供されているコード／ＡＰＩ及び／又はソフトウェア。外部でインプリメントされたものであってもよい。）を用いた場合、旧来のＳＩＰインプリメンテーションによって提供されたインタフェースがＥ２ＥＮＰ  ＵＡによって要求されるインタフェース１０１ｃに直接一致しないために、Ｅ２ＥＮＰ  ＵＡ１２８とＳＩＰ  ＵＡ１１０の間の接続を確立することが困難であることがある。新たなＥ２ＥＮＰ  ＵＡ１２８の特徴を検査するために、ＳＩＰ  ＵＡ１１０を用いてＥ２ＥＮＰ  ＵＡ１２８のためのネットワークの接続性を提供することは、プロトコルエージェント（ＳＩＰとＥ２ＥＮＰ）の間で矛盾が生じる可能性があるため、一般的には、推奨できない。これらの矛盾により、キャリアプロトコル、すなわちＳＩＰの仕様を変更する必要が生じるため、Ｅ２ＥＮＰ  ＵＡ１２８の検査のためには、ＳＩＰエミュレータ（概念的な変化を容易に採用できる）を用いることが望ましい。
【００５２】
ＳＩＰエミュレーションを行うために、ＳＩＰ代理（例えば、リモート手続呼出メカニズム：Remote Procedure Call mechanisms：ＲＰＣ）を採用することができる。Ｅ２ＥＮＰセッション記述ペイロードを検査する必要があり、必ずしも「完全な」パーサ１１２及びファクトリ１１４のインプリメンテーションを用いる必要がない場合、選択されたＳＩＰ代理に関連するソリューションを適用してもよい。
【００５３】
上述のように、ここに提案するアーキテクチャモデルに基づくプロトタイプＥ２ＥＮＰ  ＵＡ１２８インプリメンテーションは、Ｅ２ＥＮＰ概念を示すために選択されている。このインプリメンテーションは、Ｊａｖａに基づいているので、ＳＩＰ代理としては、ＲＰＣベースのビルトインＪａｖａ  ＲＭＩメカニズムが選択される。
【００５４】
ＲＭＩは、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ（ＩＦ３）プリミティブペイロードのマーシャリング又はデマーシャリングに直接関与するので、ＡＰＩに渡される全てのパラメータがｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントする必要がある。
【００５５】
Ｅ２ＥＮＰセッション記述ペイロードを検査する必要があり、（上述したＳＩＰ代理を用いる場合と同じ理由により）必ずしも「完全な」パーサ１１２及びファクトリ１１４のインプリメンテーションを用いる必要がない場合、ＲＭＩがオブジェクトを処理できるので、このようなコンテンツをストリングとしてＩＦ３を介して渡す必要はない。これに代えて、ＲＭＩマーシャリング又はデマーシャリングメカニズムを介して所定のＥ２ＥＮＰセッション記述ペイロードを表す全体のオブジェクト構造を直接交換してもよい。したがって、ここに提案するアーキテクチャモデルに基づくプロトタイプＥ２ＥＮＰ  ＵＡ１２８インプリメンテーションは、ＩＦ３プリミティブが、単にｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスのインスタンスではなく、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントするオブジェクトをパラメータとして受け入れるように設計されている。
【００５６】
このメカニズムは、以下のソフトウェアコンポーネントによってインプリメントされる。
・ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ：このＡＰＩのプリミティブは、単にｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスのインスタンスではなく、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントするオブジェクトをパラメータとして受け入れる。ＳＩＰ  ＵＡ１１０インプリメンテーションは、キャスティングメカニズム（casting mechanism）を介して、渡されたオブジェクトをｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇクラスのインスタンスとして解釈する。ＲＭＩ代理ＳＩＰインプリメンテーションは、上述したオブジェクトを「そのまま」直接シリアライズ又はデシリアライズする。
・パーサＡＰＩ１０１ｄ：このＡＰＩのプリミティブは、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントするあらゆるオブジェクトをパラメータとして受け入れる。
・ファクトリＡＰＩ１０１ｅ：このＡＰＩのプリミティブは、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントするあらゆるオブジェクトをパラメータとして受け入れる。
【００５７】
図２は、特定のＳＩＰ  ＵＡ１１０インプリメンテーション（例えば、ＪａｖａベースのＳＩＰスタック）及びＳＤＰｎｇの変更されたバージョンを扱うファクトリ１１４及びパーサ１１２インプリメンテーションに基づく上述したアーキテクチャモデルのインプリメンテーションを示している。
【００５８】
図３は、ＲＭＩ  ＳＩＰ代理に基づくアーキテクチャモデルのインプリメンテーションを示している。この場合、ファクトリ１１４ｂインプリメンテーションは、単なるダミーである。
【００５９】
ダミーのＰａｒｓｅｒＦａｃｔｏｒｙ１１８ｂとダミーのＦａｃｔｏｒｙＦａｃｔｏｒｙ１２０ｂは、それぞれ「ダミーのパーサ」実行時間インスタンス１１２ｂと「ダミーのファクトリ」実行時間インスタンス１１４ｂを作成する。
【００６０】
ここでは、「ダミー」としているが、パーサ１１２ｂ及びファクトリ１１４ｂは、オブジェクトグラフにおいて用いられているオブジェクトが「ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅ」としてタイプ化されているか否かを検査し及び／又はそれを強制することができる。
【００６１】
図４は、ソケットベースのＳＩＰ代理に基づくアーキテクチャモデルのインプリメンテーションを示している。この場合、ファクトリ１１４ｃインプリメンテーションは、単なるダミーである。但し、ＳＤＰｎｇパーサ１１２ａとＳＤＰｎｇファクトリ１１４ａにより、適切なアダプタ１２６ｃを用いて、ソケットを介して、ＸＭＬベースのストリングを送信することもできる。プリミティブは、ソケットを介して送信されるメッセージに手動でマッピングされ、これにより、専用のリモートプロシージャコール（ＲＰＣ）メカニズムがインプリメントされる。
【００６２】
ダミーのＦａｃｔｒｏｙＦａｃｔｏｒｙ１２０ｃと、ダミーのＰａｒｓｅｒＦａｃｔｒｏｙ１１８ｃは、それぞれ、「ダミーのパーサ」実行時間インスタンス１１２ｃと「ダミーのファクトリ」実行時間インスタンス１１４ｃを作成する。
【００６３】
ここでは、「ダミー」としているが、パーサ１１２ｃ及びファクトリ１１４ｃは、オブジェクトグラフにおいて用いられているオブジェクトが「ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅ」としてタイプ化されているか否かを検査し及び／又はそれを強制することができる。
【００６４】
以下のサブセクションでは、本発明に基づくＥ２ＥＮＰ  ＵＡ１２８の手法が適用されたソフトウェアコンポーネントをコンポーネントの観点から簡潔に説明する。以下では、各ソフトウェアコンポーネントについて、その要求、提供されるサービス及び制約条件と、他のソフトウェアコンポーネントとの関係についても説明する。この記述は、詳細な設計の基礎として機能する。
【００６５】
図１は、全てのソフトウェアコンポーネントと、これらのソフトウェアコンポーネントの用途の関係を示している。ソフトウェアコンポーネントは、レイヤに割り当てられ、同じ又は下位のレイヤ上のコンポーネントに関係を有することができるが、より上位のレイヤ上のソフトウェアコンポーネントとは関係を有することができない。レイヤは、下位のレイヤをカプセル化するという厳密な意味は有していない。
【００６６】
したがって、所定のＡＰＩによって提供されるサービスを用いるエンティティは、サービスユーザと呼ばれ、このＡＰＩのサービスをインプリメントするエンティティは、サービスプロバイダと呼ばれる。
【００６７】
Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂ（上述のＩＦ２）は、［ＢＲＥＮＴＡ］に開示されているＢＲＥＮＴＡモデルに基づいて、ＱｏＳアウェアアプリケーション１３０及び／又はＱｏＳブローカ１３０等のサービスユーザに対してＥ２ＥＮＰ  ＵＡ機能を提供する。このコンポーネントは、一組のインタフェースと上述したＡＰＩを介して交換される複合データタイプを定義することによって、ジェネリックＡＰＩを実現する。
【００６８】
この結果、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂにより、サービスユーザの複数のインスタンスは、同時に、Ｅ２ＥＮＰ  ＵＡ１２８機能にアクセスできる。詳しくは、Ｅ２ＥＮＰ  ＵＡ１２８は、［ＲｅｑＳｐｅｃ］に開示されているように、以下のサービスを提供する。
１．（アプリケーションとネットワークレベルの両方における）複数の代替となる能力及び／又はＱｏＳ契約の前交渉。
２．リースされた前交渉された情報の管理。
３．（アプリケーションとネットワークレベルの両方における）複数の代替となる能力及び／又はＱｏＳ契約を含むセッション確立。前交渉された情報を参照してもよい。
４．更なるローカルリソース、ピアのリソース及びネットワークリソースの予約調整を含む２と同様のサービス。
５．２及び３と同様の再交渉。
６．予約解除調整の可能性を含むセッションの解放。
【００６９】
これらのサービスを提供するために、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂは、それぞれ以下のプリミティブを提供する。
１．前交渉。
２．ｌｅａｓｅＲｅｎｅｗａｌ（リース更新。）リースの更新又は終了に用いることができる。
３．交渉。リソース予約調整が必要であるか否かを示すためにパラメータ化される。リソース予約調整が必要である場合、Ｅ２ＥＮＰ  ＵＡ１２８により、オファー側のサービスユーザは、ｂｏｏｋＮｅｇｏｔｉａｔｉｏｎ及び／又はｂｏｏｋＲｅｎｅｇｏｔｉａｔｉｏｎプリミティブを用いて互いに排他的なアクセスをリソース予約フェーズで予約できる。
４．再交渉：元の交渉フェーズにおいて、リソース予約調整が必要であると指定されている場合、Ｅ２ＥＮＰ  ＵＡ１２８により、オファー側のサービスユーザは、ｂｏｏｋＮｅｇｏｔｉａｔｉｏｎ及び／又はｂｏｏｋＲｅｎｅｇｏｔｉａｔｉｏｎプリミティブを用いて互いに排他的なアクセスをリソース予約フェーズで予約できる。
５．予約解除。
【００７０】
Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂは、以下の設計原理に基づいて設計されている。
１．プリミティブは、ＩＳＯ／ＯＳＩモデルに基づいて要求（Ｒｅｑ）プリミティブ、指示（Ｉｎｄ）プリミティブ、応答（Ｒｓｐ）プリミティブ及び確認（Ｃｆｍ）プリミティブに分類される。要求（Ｒｅｑ）プリミティブ及び応答（Ｒｓｐ）プリミティブは、特定のメッセージ交換を開始し、又はこれに応じるために、（サービスユーザとも呼ばれる）クライアントアプリケーション１３０又はミドルウェア１３０インプリメンテーションによって呼び出される（幾つかの場合、メッセージ交換は、所定のＥ２ＥＮＰ  ＵＡインプリメンテーションによって実現される抽象化により、ピア間で交換される一組の異なるメッセージを含むことができ、この他の場合、メッセージ交換は、所定のメッセージとその承認に制限される）。指示（Ｉｎｄ）プリミティブ及び確認（Ｃｆｍ）プリミティブは、特定の各メッセージ交換の到着を示し、又は所定のメッセージ交換の結果を確認するために、（サービスプロバイダとも呼ばれる）Ｅ２ＥＮＰ  ＵＡ１２８によって、サービスユーザ１３０の登録されたクライアント側に呼び出される（ここでも、幾つかの場合、メッセージ交換は、所定のＥ２ＥＮＰ  ＵＡインプリメンテーションによって実現される抽象化により、ピア間で交換される一組の異なるメッセージを含むことができ、この他の場合、メッセージ交換は、所定のメッセージとその承認に制限される）。サービスユーザ１３０のクライアント側は、これらのプリミティブをインプリメントする必要がある。所定のプロトコルメッセージ交換を開始するピアによって生成された要求プリミティブには、ターゲットピアにおける指示（Ｉｎｄ）プリミティブが対応する。所定のプロトコルメッセージ交換に応じるターゲットピアによって生成された応答（Ｒｓｐ）プリミティブには、開始側ピアにおける確認（Ｃｆｍ）プリミティブが対応する。
２．異なるサービスユーザ１３０を区別するために、Ｅ２ＥＮＰ  ＵＡ１２８は、インタフェース１０１ｂ（ＩＦ２）において、登録されたサービスユーザ１３０毎に１つのサービスアクセスポイント（ＳＡＰ）を提供する。これにより、所定のサービスユーザ１３０は、インタフェース１０１ｂ（ＩＦ２）において、一対多の関係で２つ以上のＳＡＰを用いることができる。
３．ユーザは、一度に１つのサービスユーザ１３０にしか登録できず、これは、各ユーザが、インタフェース１０１ｂ（ＩＦ２）において、１つのＳＡＰにのみにしか関連付けられないことを意味する。
４．異なるセッションレイヤプロトコル１１０（例えば、様々なＳＩＰインプリメンテーション及び／又はＲＭＩ）を同時に個別に用いるために、Ｅ２ＥＮＰ  ＵＡ１２８は、インタフェース１０１ｃ（ＩＦ３）において、登録されたセッションレイヤプロトコル毎に１つのＳＡＰを提供する。
５．基底にあるセッションレイヤプロトコルにサービスユーザ１３０を適切に関連付けるために、Ｅ２ＥＮＰ  ＵＡ１２８は、インタフェース１０１ａ（ＩＦ１）において、適切な構成メカニズムを提供し、これにより、インタフェース１０１ｂ（ＩＦ２）におけるＳＡＰをインタフェース１０１ｃ（ＩＦ３）におけるＳＡＰに一対一の関係で関連付けることができる。このようにして、所定の種類のアプリケーション１３０を用いるユーザは、構成されたセッション層プロトコルを自動的且つトランスペアレントに使用することができる。
６．インタフェース１０１ｃ（ＩＦ３）においてＳＡＰを構成する際、Ｅ２ＥＮＰ  ＵＡ１２８のセッションレイヤプロトコル１１０へのバインディング（binding）は自動的に実行される。Ｅ２ＥＮＰ  ＵＡ１２８にユーザを登録する場合は、インタフェース１０１ｃ（ＩＦ３）における所定のＳＩＰ  ＵＡ１１０ジェネリックＡＰＩにより、反対の方向のバインディングが実行され、これにより、構成されたセッションレイヤプロトコル１１０にユーザが登録される。
７．サービスユーザ１３０のＥ２ＥＮＰ  ＵＡ１２８への双方向のバインディングは、ｂｉｎｄＲｅｑプリミティブ及びｂｉｎｄＣｆｍプリミティブによって実行され、ここでは、パラメータの１つは特別な識別子であり、ＳＡＰ  ＩＤ（ｓｐＩｄ）は、インタフェース１０１ｂ（ＩＦ２）において、構成されたＳＡＰの１つを特定する。
８．如何なる所定のサービスユーザ１３０の如何なるユーザも、ｒｅｇｉｓｔｒａｔｉｏｎＲｅｑプリミティブ及びｒｅｇｉｓｔｒａｔｉｏｎＣｆｍプリミティブによって、適切な上位ＳＡＰに自らを登録することができ、ここで、パラメータの１つは、選択されたＳＡＰを特定するインタフェース１０１ｂ（ＩＦ２）において、上述したｓｐＩｄである。
９．何らかのＥ２ＥＮＰセッションをローカルで開始する際、適切な上位ＳＡＰを選択するために、以下のプリミティブは、ローカルで登録されたユーザを示し、インタフェース１０１ｂ（ＩＦ２）において、このユーザが登録されているＳＡＰを特定する新たなパラメータ「Ｓｔｒｉｎｇ  ｕｓｅｒ」を得る。
・ｒｅｎｅｗＬｅａｓｅＲｅｑ
・ｂｏｏｋＮｅｇｏｔｉａｔｉｏｎＲｅｑ
１０．適切な上位ＳＡＰを選択するために、何らかのＥ２ＥＮＰセッションをローカルで開始する際、以下のプリミティブの既存の「Ｓｔｒｉｎｇ  ｆｏｒｍ」パラメータは、ローカルで登録されたユーザを示し、インタフェース１０１ｂ（ＩＦ２）において、このユーザがＳＡＰ登録されているＳＡＰを特定する。
・ｐｒｅＮｅｇｏｔｉａｔｉｏｎＲｅｑ
・ｎｅｇｏｔｉａｔｉｏｎＲｅｑ
１１．アプリケーション又はミドルウェアＦＳＭ１３０とＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６のインスタンスは、それぞれｓｅｒｖｉｃｅＵｓｅｒＩｄとｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒＩｄによって特定される。
１２．［Ｇａｍ］に開示されている「オブザーバ設計パターン（observer design pattern）」の簡易型のバージョン（Ｊａｖａ  Ｂｅａｎｓイベントモデルに基づき、Ｊａｖａによってインプリメントされる）は、指示（Ｉｎｄ）及び／又は確認（Ｃｆｍ）プリミティブコールバックに（「バインド要求」と呼ばれるプリミティブを介して）サービスユーザ１３０を登録するメカニズムを提供する。
１３．Ｅ２ＥＮＰシグナリングの拡張性をサポートするために、プリミティブの大部分は、ペイロードを運ぶことができる。今日、これらのプリミティブの幾つかは、実際にはペイロードを運ぶよう設計されてはいないが、Ｅ２ＥＮＰの使用を改訂することもできる。このため、何らかの更なるＥ２ＥＮＰ情報のピギーバッキングが必要になることがある。
１４．異なる種類のサービスユーザ１３０がＥ２ＥＮＰ  ＵＡ１１０のサービスにアクセスできるようにするために、ペイロードは、Ｊａｖａルートクラスｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔとしてタイプ化される。このようにアプリケーション１３０又はミドルウェアは、Ｅ２ＥＮＰを介して、交換すべき情報の内部のカスタム表現（例えば、ＸＭＬベースの表現）を用いるか、又は上述したデフォルトの情報構造を利用する。
【００７１】
これにより、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂは、各アプリケーション１３０及び／又はミドルウェア１３０に依存して、Ｅ２ＥＮＰ  ＵＡ１２８のサービス、要求（Ｒｅｑ）プリミティブ及び応答（Ｒｓｐ）プリミティブのインプリメンテーションに関して適用されたＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６及び適用されたファクトリ１１４とパーサ１１２を用いる。これらのコンポーネントの選択されたインプリメンテーションに応じて、このＡＰＩを介して交換される情報のために用いられる表現の種類が決定する。
【００７２】
Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂは、オブジェクト指向パラダイムに基づいて設計され、したがって、ここでは、統一モデリング言語（ＵＭＬ）を用いてこれを説明する。Ｅ２ＥＮＰを介して交換される情報については、上述の通りである。このコンポーネントは、図５に示すように、基本的なパッケージであるｏｒｇ：：ｍｉｎｄ：：ｅ２ｅｎｐから構成される。
【００７３】
この基本的なパッケージには、以下のインタフェースが含まれている。
・プロバイダ５０４は、ここに説明する使用に準拠するＥ２ＥＮＰ  ＵＡプロバイダインプリメンテーションが要求（Ｒｅｑ）プリミティブ及び応答（Ｒｓｐ）プリミティブをサポートするインタフェースを表す。プロバイダインタフェース５０４に提供されるプリミティブのリストをＴＡＢ１に示す。
・Ｅ２ＥＮＰＵｓｅｒＡｇｅｎｔＬｉｓｔｅｎｅｒ５０２は、サービスユーザが、Ｅ２ＥＮＰ  ＵＡ１２８によって生成される指示及び／又は確認（Ｃｆｍ）プリミティブの割込をインプリメントする全てのインタフェースを般化している。
【００７４】
Ｅ２ＥＮＰＵｓｅｒＡｇｅｎｔＬｉｓｔｅｎｅｒインタフェース５０２によって提供されるプリミティブのリストをＴＡＢ２に示す。
【００７５】
Ｅ２ＥＮＰＵｓｅｒＡｇｅｎｔＬｉｓｔｅｎｅｒインタフェース５０２は、ＯｆｆｅｒｅｒＬｉｓｔｅｎｅｒインタフェース５０６とＡｎｓｗｅｒｅｒＬｉｓｔｅｎｅｒインタフェース５０８に特化される。ＯｆｆｅｒｅｒＬｉｓｔｅｎｅｒインタフェース５０６は、特に、Ｅ２ＥＮＰを開始するアプリケーション又はミドルウェアのために設計され、ＡｎｓｗｅｒｅｒＬｉｓｔｅｎｅｒインタフェース５０８は、特に、Ｅ２ＥＮＰ手続に応じるアプリケーション１３０又はミドルウェア１３０のために設計される。
【００７６】
ＴＡＢ３は、ＯｆｆｅｒｅｒＬｉｓｔｅｎｅｒインタフェース５０６によって提供されるプリミティブのリストを示し、ＴＡＢ４は、ＡｎｓｗｅｒｅｒＬｉｓｔｅｎｅｒインタフェース５０８によって提供されるプリミティブのリストを示している。
【００７７】
前交渉及び交渉プリミティブによって渡される「ｔｏ／ｆｒｏｍ」パラメータは、Ｅ２ＥＮＰユーザ（それぞれオファー側とアンサ側）を特定するアドレスである。Ｅ２ＥＮＰ  ＵＡ１２８は、これらのアドレスを所定のセッションレイヤプロトコルによって用いられる特定の統語構造にマッピングする。このセッションレイヤプロトコルは、Ｅ２ＥＮＰ情報をピギーバッキングするために用いられるプロトコルであり、ここでは、ＳＩＰである。したがって、Ｅ２ＥＮＰは、特定のセッションレイヤプロトコルから独立しており、更に、Ｅ２ＥＮＰ  ＵＡ１２８によって用いられているトランスポートプロトコルからも独立させることができる。この目的で、特に、Ｅ２ＥＮＰのために設計された新たな統語構造をここに提案する。
【００７８】
図５Ｂは、オブジェクト指向パラダイムによって設計されたＥ２ＥＮＰ  ＵＡファクトリ１０８と管理エンティティ１０２の間のＥ２ＥＮＰ管理ＡＰＩ１０１ａ（ＩＦ１）を示している。このように、Ｅ２ＥＮＰ管理ＡＰＩ１０１ａ（ＩＦ１）は、ＭａｎａｇｅｒＰｒｏｖｉｄｅｒインタフェース５１０とＭａｎａｇｅｒＬｉｓｔｅｎｅｒインタフェース５１２といったコンポーネントを含む基本的なパッケージから構成されている。インタフェースＩＦ１を介してパーサインプリメンテーション１１２とファクトリインプリメンテーション１１４を構成するために、ＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｑｕｅｓｔ５１４とＰａｒｓｅｒＦａｃｔｏｒｙＣｏｎｆｉｇｕｒａｔｉｏｎ５１６のクラスが用いられる。
【００７９】
図６は、強化されたＢＮ記法（Augmented Backus-Naur Form：ＡＢＮＦ）を用いて、このような普遍的なリソース識別子（ＵＲＩ）統語構造の形式的設計をしている。したがって、この仕様は、［Ｒｏｓ１］に開示されているＳＩＰ  ＵＲＩ統語構造仕様と同様であるが、ここでは、敢えて、ＩＰアドレス及び／又はポート番号を除いて、如何なるトランスポートプロトコルパラメータも示していない。Ｅ２ＥＮＰ  ＵＲＩの具体例として「e2enp://dave:vG$l809@acme.com」はパスワード「vG$l809」を用いる「acme」という組織における「Dave」という名のユーザを表す。「//」は、アドレス内に示されないデフォルトユーザのケースのためのセパレータである。例えば、「e2enp://:xyz%45637@acme.com」は、パスワード「xyz%45637」を用いるデフォルトユーザ（アドレス内に示されていない）を示している。
【００８０】
Ｅ２ＥＮＰアドレスコンポーネントの完全な又は部分的な用途は、主に、それぞれ適用されたセッションレイヤプロトコル（例えば、ＳＩＰ）の一部である領域モデル（プロキシ）とアドレス解決メカニズムに依存する。Ｅ２ＥＮＰ  ＵＡ１２８は、セッションレイヤプロトコルが既に何らかのプロキシ及び／又はネットワークパスを特定するリダイレクションメカニズムを提供している場合、通信するパートナーを特定するために、少なくともユーザ（デフォルトユーザ）名とドメイン名を用いる必要がある。
【００８１】
以下のサブセクションでは、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂによって実行される手続を一組のＵＭＬメッセージシーケンス図（Message Sequence Chart：以下、ＭＳＣという。）によって説明する。
【００８２】
図７は、Ｅ２ＥＮＰ  ＡＰＩを介したプリミティブの交換に関する単純な前交渉シナリオを示している。これらのプリミティブに関して、ＯｆｆｅｒｅｒＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ７０４とＡｎｓｗｅｒｅｒＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ７０６の間では、特定のトランスポートプロトコルメッセージが交換されるが、一般的な表現とするために、図７ではこれらを示していない。
【００８３】
図８は、ＱｏＳ交渉とリソース予約調整処理（resource reservation coordination processes）に注目した単純なセッション確立シナリオのＭＳＣである。このシナリオでは、説明を簡潔にするために、オファー側からのリソース予約完了の確認は、アンサ側で同様の確認が行われる前に到着するものとする。同様に、この単純なシナリオでは、説明を簡潔にするために、リソース予約処理は、最初に要求した量のリソースの予約に成功するものとする。
【００８４】
再交渉手続は、以下に示すプリミティブの名称の変更を除いて、交渉手続と同様である。
【００８５】
【表２】
2006504363.tif 000005
【００８６】
キャッシュ１０４は、異なるオブジェクト識別子を保存するためのデータベースである。サービスユーザ識別スキームをＥ２ＥＮＰ［ＲｅｑＳｐｅｃ］のために指定されたものから分離するために、Ｅ２ＥＮＰキャッシュ１０４は、以下の目的で用いられる。
・［ＲｅｑＳｐｅｃ］において特定されているＥ２ＥＮＰセッション識別子を保存し、読み出す。
・Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６（ｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒＩｄ）によって処理されるＥ２ＥＮＰセッション識別子を保存し、読み出す。
・Ｅ２ＥＮＰ  ＵＡ  ＡＰＩサービスユーザセッション識別子（ｓｅｒｖｉｃｅＵｓｅｒＩｄ）を保存し、読み出す。
【００８７】
キャッシュ１０４は、異なる識別子及びＥ２ＥＮＰ  ＵＡ１２８によって設定される以下に示す異なる基準に基づいて検索可能である必要がある。Ｅ２ＥＮＰ  ＵＡ１２８は、キャッシュ管理の機能を担っている。
【００８８】
キャッシングされたオブジェクトは、オブジェクトカテゴリの識別子に対応する。キャッシュ１０４は、次のような２つの種類のデータを保存する。
・予めキャッシングされたデータ：Ｅ２ＥＮＰ  ＵＡは、所定のＥ２ＥＮＰ前交渉又は交渉手続の実行の間に情報（ｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒＩｄによってプライマリキーとしてインデクスが付され、ｓｅｒｖｉｃｅＵｓｅｒＩｄ及び［Ｒｅｑ−Ｓｐｅｃ］において特定されているＥ２ＥＮＰセッション識別子によってセカンダリキーとしてインデクスが付される）をプレキャッシングする。一旦、所定の手続が問題なく完了すると、プレキャッシングされたデータは、キャッシングされたまま残り、これにより、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂサービスユーザは、［ＲｅｑＳｐｅｃ］に開示されているように、後のＥ２ＥＮＰセッションの間このようなデータを参照することができる。
・キャッシングされたデータ：この情報は、後に、新たなＥ２ＥＮＰ前交渉又は交渉手続の間、既にピア間で（前）交渉されたデータへの参照情報として用いることができる。各Ｅ２ＥＰＮセッションについて、キャッシュ１０４は、所定のＳｅｒｖｉｃｅＵｓｅｒＩｄと、［ＲｅｑＳｐｅｃ］に開示されている対応するＥ２ＥＮＰセッション識別子の間の関係を保存する。このキャッシュ１０４内の各エントリは、［ＲｅｑＳｐｅｃ］に開示されているように、ピアの間でリースされ、時間の経過に伴って更新する必要がある。サービスユーザ１３０は、自らのリース及び（前）交渉された情報を管理する機能を担っている。以前のＥ２ＥＮＰセッションにおける相関関係に関する情報については、キャッシュ１０４は、非持続的に保存するのみである。
【００８９】
Ｅ２ＥＮＰキャッシュ１０４は、交渉オブジェクトＩＤを管理するために用いられるデータベースである。Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、キャッシュ１０４サービスを要求する。本発明の一実施形態では、キャッシュ１０４は、相互に参照する一組のｊａｖａ．ｕｔｉｌ．Ｈａｓｈｔａｂｌｅオブジェクトとして設計される。これに代わるタプルスペース技術に基づくインプリメンテーションについては、更に研究の余地がある。Ｅ２ＥＮＰ  ＵＡ１２８インプリメンテーションを複雑にしないために、キャッシュ１０４とＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の間のキャッシュＡＰＩ１０３は、同期インタフェースを表す。
【００９０】
本発明のインプリメント例においては、以下のような２段階のキャッシュ１０４を用いる。
・キャッシュ１０４のレベル１（Ｌ１）では、タプルｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒＩｄ、ｓｅｒｖｉｃｅＵｓｅｒＩｄ、ＦｒｏｍＳＩＰＡｄｄｒｅｓｓ、ＴｏＳＩＰＡｄｄｒｅｓｓ、Ｅ２ＥＮＰＳｅｓｓｉｏｎ−ＩＤといったタプルの形式でプレキャッシングされた情報セーブする。ここで、ＦｒｏｍＳＩＰＡｄｄｒｅｓｓ及びＴｏＳＩＰＡｄｄｒｅｓｓは、デュアルシージャ（dual seizures）の検出を可能にし、プライマリキーは、ｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒＩｄである。
・キャッシュ１０４のレベルＴｗｏ（Ｌ２）では、ｓｅｒｖｉｃｅＵｓｅｒＩｄ、Ｅ２ＥＮＰＳｅｓｓｉｏｎＩＤといったタプルの形式でプレキャッシングされた情報を保存する。プライマリキーは、ｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒＩｄである。
【００９１】
２つのレベルのキャッシュ１０４は、Ｅ２ＥＮＰ  ＵＡ１２８によって開始及び管理される、［Ｇａｍ］に開示されている２つの個別の単集合オブジェクトとしてインプリメントされる。キャッシュオブジェクトは、Ｅ２ＥＮＰ  ＵＡ１２８のインスタンス内で実行される。図９は、キャッシュインプリメンテーションを含む、ｏｒｇ：：ｍｉｎｄ：：ｅ２ｅｎｐ：：ＣａｃｈｅサブパッケージのＵＭＬクラス図である。
【００９２】
単集合ＬｅｖｅｌＯｎｅＣａｃｈｅ９０２及びＬｅｖｅｌＴｗｏＣａｃｈｅ９０４は、それぞれキャッシュレベルＬ１及びキャッシュレベルＬ２を表し、キャッシュエントリ（それぞれＬｅｖｅｌＯｎｅＥｎｔｒｙ９０６及びＬｅｖｅｌＴｗｏＥｎｔｒｙ９０８）を作成し、検索し、解放するＡＰＩを提供する。
【００９３】
ＴＡＢ５及びＴＡＢ６は、それぞれ第１及び第２のキャッシュレベル（Ｌ１とＬ２）のＡＰＩによって提供されるメソッドを示している。
【００９４】
以下のサブセクションでは、ＸＭＬベースのシリアル化されたトランスポート表現は、ＸＭＬスキーマ定義によって定義されるものとする。トランスポート表現は、このようなフォーマットを最初から定義するのではなく、ベースラインＳＤＰｎｇフォーマット定義に基づき、これを用いる。また、互換性を別にすれば、サードパーティのライブラリと、［Ｋｕｔ２］に開示されているＳＤＰｎｇのために設計されたプロファイル定義を利用し、これらの利点を享受することも可能である。このような具体例としては、以下に限定されるものではないが、例えば、リアルタイムプロトコル（Real-Time Protocol：ＲＴＰ）、オーディオ及びビデオコーデックプロファイル等を用いてもよい。
【００９５】
ファクトリＡＰＩ１０１ｅとパーサＡＰＩ１０１ｄが共通のトランスポート表現統語構造をどのように共有するかを説明するために、以下のサブセクションでは、このようなフォーマットのための１つの可能な定義を説明する。Ｅ２ＥＮＰのＸＭＬ記述は、ベースラインＳＤＰｎｇ  ＸＭＬ記述フォーマットを拡張して用いる。
【００９６】
Ｅ２ＥＮＰのためのＸＭＬ表現（以下では、Ｅ２ＥＮＰは、この表現と同じ意味で用いられる）は、ＳＤＰｎｇベースラインＸＭＬ定義への拡張となるように選択されている。このような選択の主な理由は、ＩＥＴＦによってＳＤＰｎｇが標準化されると予想され、これにより、以下のような主な利点が得られるためである。
・ＳＤＰｎｇへの拡張としてのＥ２ＥＮＰは、ＳＤＰｎｇに類似するプロファイルとライブラリ定義への外部の貢献からの利益を享受することができる。既に、ＳＤＰｎｇドラフト［Ｋｕｔ２］で指摘されている具体例、すなわち、オーディオ及びＲＴＰプロファイルがある。これらの拡張は、既にＥ２ＥＮＰ  ＸＭＬの仕様に組み込まれている。
・将来のＳＤＰｎｇ規格をインプリメントするアプリケーション１３０は、理想的には、単にＥ２ＥＮＰモジュールをアプリケーション１３０にリンクさせることによって、Ｅ２ＥＮＰをサポートするようにより容易に拡張することができる。同様に、異なる機種が混在する環境では、Ｅ２ＥＮＰをサポートしないアプリケーション１３０は、ＳＤＰｎｇ固有の部分で動作でき、したがって、相互運用性が完全には失われない。
【００９７】
Ｅ２ＥＮＰ  ＸＭＬ表現は、Ｗ３Ｃによって定義されているように、ＸＭＬスキーマ定義によって形式的に特定される。スキーマの定義は、大まかに３つの部分に分けられ、その１つは、例えば、属性値のための列挙（enumerations）等のタイプの定義又は複合タイプとしての共通のコンテンツモデルの定義を含む。メインの部分は、代理グループメカニズムを用いてＳＤＰｎｇにプラグされるトップレベルＥ２ＥＮＰセクション（すなわち、エレメント）を定義する。そして、第３の部分は、ＳＤＰｎｇに関係しないＥ２ＥＮＰ特有のエレメントを定義し、トップレベルのエレメントのコンテンツモデルを完全に定義するために用いられる。
【００９８】
図１０に示すように、「本来ＳＤＰｎｇにおいて定義されている」ｄｅｓｃＴｙｐｅ１００１は、Ｅ２ＥＮＰ固有のヘッダセクション「目的：purpose」１００２が「ｄｅｓｃルート」エレメントの正式な子となるように再定義される。Ｅ２ＥＮＰは、「ｓｄｐｎｇ：ｄ」エレメントの代理として用いることができる「ｓｄｐｎｇ：ｄｅｆ」１００３セクションの唯一の有効な子である「ｑｏｓｄｅｆ」セクションを定義し、同様に、「ｓｄｐｎｇ：ｃ」の代わりに、「ｓｄｐｎｇ：ｃｆｇ」１００４セクションの唯一の有効な子となる「ｑｏｓｃｆｇ」を用いることができる。Ｅ２ＥＮＰ固有のエレメントタイプについては、後述する。
【００９９】
図１１は、ＳＤＰｎｇへの拡張とプラグインを示し、代理グループのエレメントを用いて、このグループのヘッドエレメントを置換する手法を説明している。
【０１００】
ここで「ｓｄｐｎｇ：ｄ」１１０７は、ヘッドエレメントであり、代理グループのメンバ、すなわち「オーディオ：ｃｏｄｅｃ」１１０８、「ｅ２ｅｎｐ：ｑｏｓｄｅｆ」１１０９、「ｒｔｐ：ｐｔ」１１１０、「ｒｔｐ：ｔｒａｎｓｐｏｒｔ」１１１１（ネスト構造の構造代理グループのヘッドエレメントとなる）、「ビデオ：ｃｏｄｅｃ」１１１３の何れによっても置き換えることができる。このようにしてＸＭＬネームスペース概念に結合された代理グループメカニズムを用いることによって、如何なるＸＭＬスキーマ定義に対してもモジュールの拡張を定義することができる。［Ｂｏｓ２］に開示されているオプションサブグループをサポートするように代理グループメンバ「ｒｔｐ：ｕｄｐ」１１１２を更に拡張し、これにより、［Ｂｏｓ２］において提案されているものと同様のオプションを組み込んでもよい（図１１には示していない）。
【０１０１】
「ｑｏｓｃｆｇ」エレメント１４００は、「ｓｄｐｎｇ：ｃ」のヘッダが付された代理グループで定義され、これは、「ｓｄｐｎｇ：ｃｆｇ」セクションの有効な子となる。
【０１０２】
図１２に示す「目的」１２０１エレメントを用いることにより、交渉処理に関する追加的な情報を外部の記述によって伝えることができる。図１２は、目的エレメントをどのように定義するかに関する包括的構造を示している。
【０１０３】
これにより、ヘッダは、現在のメッセージがどのセッション属するかを定義する。また、これにより、「使用：use」１２０２エレメントによって、前のセッションへの参照を確立することができ、これらのセッションから定義を参照できるようにすることができる。
【０１０４】
Ｅ２ＥＮＰメッセージが何を意図しているかに応じて、「記述：description」１２０３エレメント又は「調停：mediation」１２０４エレメントの何れかが存在している必要がある。例えば「記述」１２０３エレメントに基づき、要求（Ｒｅｑ）又は応答（Ｒｓｐ）等のメッセージの種類と、如何なる交渉モード（プッシュ、プル、プッシュプル）を用いるべきかを宣言することができる。
【０１０５】
図１３は、「ｑｏｓｄｅｆ」エレメント１３００の包括的構造を示している。但し、ｑｏｓｄｅｆエレメント１３００の「名称」属性の値に応じて、正式な子エレメントの用途は、制約される。ここでは、２つの可能な値として「能力：capabilities」及び「契約：contracts」がある。「ｑｏｓｄｅｆ」セクション１３００は、ピアの能力を指定するか、又は、契約の場合には、Ｅ２ＥＮＰ  ＵＡ１２８を用いて、エンティティによって妥当性が検証された契約を定義する。
・能力の指定：「ｑｏｓｄｅｆ」エレメント１３００の属性の値が「能力：capabilities」である場合、有効な子エレメントは、「オーディオ：ｃｏｄｅｃ」１３０１、「ビデオ：ｃｏｄｅｃ」１３０２及び「ｒｔｐ：ｐｔ」１３０３である。各コーデックエレメントは、オーディオ及びビデオコーデックとそれらの構成に関して、ピアのシステム能力を表す。「ｒｔｐ：ｐｔ」１３０３エレメントを用いることによって、所定の能力について必要なＲＴＰペイロードフォーマットを指定することができる。
・契約の指定：この場合、ｑｏｓｄｅｆエレメント１３００の「名称」エレメントの属性値は、「契約：contracts」である必要がある。次に、有効な子エレメントは、「ポリシ：policy」１３０４と、「オーディオ：audio」１３０５と、「ビデオ：video」１３０６である。「ポリシ」エレメント１３０４は、一回だけ出現する必要がある。「ポリシ」エレメント１３０４は、実施するリソース管理ポリシを交渉するポリシを指定する。ポリシを用いて、システム挙動の１又は複数の側面を最適化することができる。具体的には、例えば、メモリ使用量、ＣＰＵ負荷、ネットワークトラヒック又は電力消費量を最適化することができる。より高い柔軟性を実現するために、プレディケートを用いることによって、これらの基本的な側面を結合してもよい。「ポリシ」１３０４エレメントに続くエレメントは、「オーディオ」１３０５、「ビデオ」１３０６、「データ」１３０８及び「制御」１３０７エレメントのうちの１つ以上であってもよい。これらのエレメントは、各データストリームに関するＱｏＳ契約を記述する。「ｒｔｐ：ｍａｐ」１３０９エレメントを用いることによって、アプリケーションレベルＱｏＳ契約と、特定のＲＴＰペイロードフォーマットとの間のマッピングを定義することができる。
【０１０６】
図１４は、「ｑｏｓｃｆｇ」エレメント１４００の包括的構造を示している。このセクションにより、ストリームレベルＱｏＳ契約から始まる様々な抽象化のレベルにおいて、ＱｏＳ相関関係及び時間同期制約とともに、適応化パス（adaptation path：以下、ＡＰという。）を定義することができる。各抽象レベルは、このセクションの属性「名称」によって特定される。可能な値としては、「ストリーム：stream」、「ストリームグループ：stream-group」、「セッション：session」及び「アプリケーション：application」等がある。このようにしてストリームレベル適応化パス及びよりハイレベルのＡＰを含む異なるレベルにおいて適応化パスを定義することができる。「コンテキスト：context」１４０１エレメントは、所定のストリームの可能な関連付けを定義し、これにより、時間同期及び／又はＱｏＳ相関制約を定義することができる。このように、「コンテキスト」１４０１エレメントは、基本的にハイレベルのＱｏＳ契約を記述する。
【０１０７】
以下のサブセクションでは、パーサＡＰＩ１０１ｄの概要を簡潔に説明する。
【０１０８】
パーサＡＰＩ１０１ｄは、幾つかのトランスポート表現で書かれた記述を解析し、ＩＦ２に基づくオブジェクト表現を生成するために用いることできるプリミティブを提供する。Ｅ２ＥＮＰ  ＵＡ１２８とパーサ１１２を疎結合するために、このオブジェクト表現は、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔとして表現されるように抽象化される。既に指摘したように、トランスポート表現のための唯一の要求は、トランスポート表現がｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントする必要があるという点である。これは、トランスポート表現がタイプ化されず、したがって、トランスポート表現が実際にどのように表されるかに関して、高い柔軟性を有することを意味する。
【０１０９】
トランスポート表現は、外部の以前に定義されたエンティティへの参照情報を含んでいてもよい。これらの参照情報は、パーサ１１２によっては、処理されず、解決されないまま残される。すなわち、この情報は、後に、Ｅ２ＥＮＰ  ＵＡ１２８又は、より高いレイヤのエンティティで処理される。
【０１１０】
パーサＡＰＩ１０１ｄは、渡すべき各メッセージのタイプ毎に１つのプリミティブを提供する。このように、メッセージのタイプは、暗示的に表現され、オブジェクトモデルにおいて考慮する必要はない。パーサ１１２は、各メッセージのタイプ毎に各メッセージのタイプのオファーとアンサを解析する１つのプリミティブを提供する。したがって、パーサＡＰＩ１０１ｄプリミティブに関する図１５に示す汎用的なパターンは、以下の通りとなる。
オブジェクトｐａｒｓｅＸＸＸ（シリアル化可能な入力：Serializable input）
ここで、「ＸＸＸ」は、ＮｅｇＯｆｆｅｒやＰｒｅＮｅｇＡｎｓｗｅｒ等のプリミティブの名称のプレースホルダ（placeholder）を示す（この他の詳細に関しては、後述するＡＰＩの定義参照）。
【０１１１】
これらの一般的な解析処理に加えて、パーサＡＰＩ１０１ｄは、シリアル化された表現でラッピングされたコンテンツをナビゲートするための幾つかの特別なプリミティブを提供する。クライアントは、これらのプリミティブを用いて、実際の表現から独立して、抽象化レベルの特定の情報又はデータにアクセスすることができる。したがって、将来、プロトコル拡張に起因して表現が変化しても、情報へのアクセス方式が変化しないので、古いバージョンの表現を用いるクライアントは、新たな変化による影響を受けない。
【０１１２】
実際のキャリアプロトコルは、交換可能である必要があるため、同様に、実際のパーサ１１２インプリメンテーションを交換できる機能を提供する必要がある。上述したように、このメカニズムは、パーサ１１２インプリメンテーションとキャリアプロトコルとについて同じでなければならない。
【０１１３】
したがって、プリミティブを提供するＰａｒｓｅｒＦａｃｔｏｒｙ  ＡＰＩは、実際のパーサ１１２インプリメンテーションインスタンスを作成するよう定義される（図１に示すファクトリ１１８は、このようなＰａｒｓｅｒＦａｃｔｏｒｙのインプリメンテーションを示している）。更に、如何なるキャリアプロトコルについても、新たな実際のパーサ１１２インプリメンテーションを登録することができる。
【０１１４】
Ｅ２ＥＮＰ  ＵＡ１１０とパーサ１１２の間の通信は、非同期であってもよく、例えば、能動要求インタフェースと受動確認インタフェースとによってインプリメントしてもよい。但し、性能及び柔軟性の向上と、Ｅ２ＥＮＰのＦＳＭ１０６の状態モデルの複雑性は対立するため、このようなオプションは、基本的な設計には、好適であるとは言えない。この解決の結果の１つとして、Ｅ２ＥＮＰ  ＵＡ１２８とパーサ１１２（並びにファクトリ１１４）は、同時に通信することができ、したがって、共通アドレス空間を共有する必要があり、これは、ほとんどの状況において、妥当な仮定である。
【０１１５】
この解決の他の結果として、パーサ１１２（及びファクトリ１１４）は、スレッドセーフで、再入可能なライブラリとして設計する必要がある。
【０１１６】
構文解析の間に生成され、その結果、呼出側のＥ２ＥＮＰ  ＵＡ１２８に戻されるオブジェクト表現は、パーサ１１２とＥ２ＥＮＰ  ＵＡ１２８の疎結合を提供するために、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔクラスのみを用いることによって非常に抽象的に記述される。Ｅ２ＥＮＰＵＡ１２８において用いられる所定のトランスポート表現及び所定のオブジェクトモデルについて、パーサ１１２をインプリメントする実際のクラスは、構成によって互いに適合する必要がある。
【０１１７】
実際のパーサ１１２及びファクトリインプリメンテーション１１４は、それぞれ、トランスポート表現について、共通のフォーマットに同意する必要がある。既存の規格の使用が推奨され、仮定されている場合であっても、これらのフォーマットの定義は、インプリメンテーション固有であり、実際のパーサ１１２とファクトリに１１４コンポーネントに対応する。したがって、ベースラインＳＤＰｎｇの定義に互換性を有するフォーマットが定義されている。
【０１１８】
ＰａｒｓｅｒＦａｃｔｏｒｙ  ＡＰＩによって提供される登録機能は、異なる手法で処理することができる。但し、これは、実際のＰａｒｓｅｒＦａｃｔｏｒｙ１１２インプリメンテーションに制約される。登録について実行できる幾つかのオプションとしては、以下のような処理がある。
・登録は、複数のアプリケーションのライフサイクルに亘って存続するために、永続的に保存してもよい。
・登録は、他のアプリケーション１３０において使用するために、公開してもよく、これも永続的な保存を含意する。
・登録は、現在のアプリケーションのライフサイクルの間のみ、一時的に保存してもよい。
【０１１９】
アプリケーション１３０は、インスタンスの各ｇｅｔＴｙｐｅ（）メソッドを呼び出して、返された値の同一性を比較することにより、パーサ１１２及びファクトリ１１４の一致する対をインスタンス化しているか否かを確認してもよい。アプリケーション１３０が一致しないパーサ１１２及びファクトリ１１４の対を使用すると、予測できない結果が生じる虞があり、若しくは、未定義の又は誤った振る舞いを引き起こす可能性がある。
【０１２０】
以下では、この依存関係を簡潔に説明する。
・ＩＦ２オブジェクトモデル：これは、パーサ１１２の実際のインプリメンテーションが満たすべき暗黙の依存関係にすぎない。通常、パーサ１１２が単にｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔインスタンスを作成するという事実によって、この依存関係は排除される。しかしながら、実際に作成される明確に構成されたシステムにおいては、Ｅ２ＥＮＰ  ＵＡ１２８では、特定のオブジェクモデルクラスのインスタンスが用いられる。
・トランスポート表現：勿論、上述の依存関係と同様に、実際のパーサ１１２は、自らが作成しなくてはならないシステムに関する明確な構造を必要とする。したがって、これは、トランスポート表現のそれぞれの定義に依存する。但し、通常は、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅを用いてトランスポート表現を抽象的に記述することによって、この依存関係は、設計から排除される。
【０１２１】
ＴＡＢ７は、パーサＡＰＩ１０１ｄによってインプリメントすべきプリミティブを列挙している。一方、ＴＡＢ８は、特定のパーサ１１２を生成するためにインプリメントすべきプリミティブを示している。
【０１２２】
ＰａｒｓｅｒＦａｃｔｏｒｙ  ＡＰＩは、パーサ−ファクトリインプリメンテーションとも呼ばれるパッケージｏｒｇ．ｍｉｎｄ．ｅ２ｅｎｐ．ｃｏｎｔｅｎｔのクラスＥ２ＥＮＰＣｏｎｔｅｎｔ−ＨａｎｄｌｅｒＦａｃｔｏｒｙによって実現される。このクラスは、全てのクライアントが先に作成された登録を使用できるように単集合インスタンスとして設計される。現在作成されている単集合インスタンスは、初期的なインプリメンテーションであるが、将来的には、単集合インスタンスのために用いられるクラスを決定するために、（特定のシステムプロパティに基づいて）構成可能な手法を提供することが計画されている。ＴＡＢ１１は、Ｅ２ＥＮＰ−ＣｏｎｔｅｎｔＨａｎｄｌｅｒＦａｃｔｏｒｙクラスによって提供される処理を示している。
【０１２３】
以下のサブセクションでは、ＸＭＬベースのトランスポート表現に必要なパーサ１１２のインプリメンテーションを簡潔に説明する。ここでは、ＸＭＬベースのトランスポート表現のための可能なパーサ１１２インプリメンテーションを提案する。図１７は、１つのＤｏｃｕｍｅｎｔＮｏｄｅ１７０４に統合され、ドキュメントルートエレメントとして解釈できるクラスＤｏｃｕｍｅｎｔＴｒｅｅ１７０２としてモデル化されたドキュメントオブジェクトモデル（ＤＯＭ）ツリーの包括的構造を示している。各ＤｏｃｕｍｅｎｔＮｏｄｅ１７０４は、０〜Ｎの子を統合し、これにより、ツリー構造を再帰的に記述する。
【０１２４】
［Ｇａｍ］に開示されているように、「ビジター設計パターン（visitor design pattern）」を用いることによって、この表現のためのパーサ１１２をインプリメントできる。図１８は、構造的な概要を示している。ここでは、ジェネリックパーサ１１２ビジタークラスｐＶｉｓｉｔｏｒ１８０８は、１〜Ｎ個のＤＯＭＮｏｄｅｓ１８０６を使用し、又は、正確に言うと、訪れる（visit）よう定義される。特別に導出された各ＤＯＭＮｏｄｅサブクラスについて、導出されたＤＯＭＮｏｄｅｓを処理するために、特化されたビジターが定義される。（「ビジターパターン」がサブクラスのみを扱うよう意図されている場合であっても、この概念は、異なるエレメントノードがそれら自身のカテゴリとして解釈されるように容易に拡張できる）。
【０１２５】
以下では、ファクトリ１１４に適用されるアプリケーションプログラミングインタフェース（ＡＰＩ）を簡潔に説明する。
【０１２６】
ファクトリＡＰＩ１０１ｅは、ＩＦ２に基づく所定のオブジェクト表現用のトランスポート表現を作成するために用いることができるプリミティブを提供する。Ｅ２ＥＮＰ  ＵＡ１２８とファクトリ１１４の疎結合は、（ファクトリインタフェース１０１ｅを通過する）オブジェクト表現をｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔとして抽象化することによって実現される。既に指摘したように、トランスポート表現のための唯一の要求は、トランスポート表現がｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅインタフェースをインプリメントしなくてはならないということである。したがって、このＡＰＩによって定義された全てのプリミティブは、「ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅ」オブジェクトを返す。
【０１２７】
オブジェクト記述は、外部の、既に定義されているエンティティへの参照情報を含んでいてもよい。これらの参照情報は、ファクトリ処理によって処理されることもなく、参照を外されることもなく、ただ単に使用される。
【０１２８】
パーサ１１２と同様、ファクトリＡＰＩ１０１ｅは、各メッセージのタイプ毎に１つの渡すべきプリミティブを提供する。このように、メッセージのタイプは暗示され、オブジェクトモデルにおいて考慮する必要はない。図１９に示すように、ファクトリＡＰＩプリミティブのための汎用的なパターンは以下の通りである。
シリアル化可能ｃｒｅａｔｅＸＸＸ（オブジェクト入力）
ここで、「ＸＸＸ」は、ＮｅｇＯｆｆｅｒやＰｒｅＮｅｇＡｎｓｗｅｒ等のプリミティブの名称のプレースホルダ（placeholder）を示す（この他の詳細に関しては、後述するＡＰＩの定義参照）。
【０１２９】
実際のキャリアプロトコルは、交換可能である必要があるため、実際のファクトリ１１４インプリメンテーションもまた、交換可能となるような機能を提供する必要がある。上述したように、このメカニズムは、ファクトリ１１４インプリメンテーションとキャリアプロトコルとについて、同じでなければならない。したがって、ＦａｃｔｏｒｙＦａｃｔｏｒｙ  ＡＰＩは、実際のファクトリ１１４インプリメンテーションインスタンスを作成するプリミティブを提供するよう定義される（図１に示すファクトリ１２０は、このようなＦａｃｔｏｒｙＦａｃｔｏｒｙのインプリメンテーションを示している）。更に、ファクトリＡＰＩ１０１ｅとパーサＡＰＩ１０１ｄが共通のトランスポート表現統語構造をどのように共有するかを示すために如何なるキャリアプロトコルについても、新たな実際のファクトリ１１４インプリメンテーションを登録することができる。
【０１３０】
Ｅ２ＥＮＰ  ＵＡ１２８とファクトリ１１４の間の通信は、非同期であってもよく、例えば、能動要求インタフェースと受動確認インタフェースとによってインプリメントしてもよい。但し、性能及び柔軟性の向上と、Ｅ２ＥＮＰのＦＳＭ１０６の状態モデルの複雑性は対立するため、このようなオプションは、本発明の実施形態では用いない。この解決の結果の１つとして、Ｅ２ＥＮＰ  ＵＡ１２８とファクトリ１１４（並びにパーサ１１２）は、同時に通信することができ、したがって、共通アドレス空間を共有する必要があり、これは、ほとんどの状況において、妥当な仮定である。
【０１３１】
この解決の他の結果として、ファクトリ１１４（及びパーサ１１２）は、スレッドセーフで、再入可能なライブラリとして設計する必要がある。
【０１３２】
ファクトリ１１４とＥ２ＥＮＰ  ＵＡ１２８の疎結合を提供するために、ファクトリ１１４によって生成され、その結果、呼出側のＥ２ＥＮＰ  ＵＡ１２８に戻されるトランスポート表現は、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔクラスを用いることによって抽象的に記述される。同様にｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔクラスは、ファクトリ１１４プリミティブの入力を抽象的に記述する。したがって、Ｅ２ＥＮＰＵＡ１２８において用いられる所定のトランスポート表現及び所定のオブジェクトモデルについて、ファクトリ１１４をインプリメントする実際のクラスは、構成によって互いに適合する必要がある。
【０１３３】
実際のパーサ１１２及びファクトリインプリメンテーション１１４は、それぞれ、トランスポート表現について、共通のフォーマットに同意する必要がある。既存の規格の使用が推奨され、仮定されている場合であっても、これらのフォーマットの定義は、インプリメンテーション固有であり、実際のパーサ１１２とファクトリに１１４コンポーネントに対応する。したがって、ベースラインＳＤＰｎｇの定義に互換性を有するフォーマットが提案されている。
【０１３４】
ＦａｃｔｏｒｙＦａｃｔｏｒｙ１２０によって提供される登録機能は、異なる手法で処理することができる。登録について実行できる幾つかのオプションとしては、これらに限定されるものではないが、例えば、以下のような処理がある。
・登録は、複数のアプリケーションのライフサイクルに亘って存続するために、永続的に保存してもよい。
・登録は、他のアプリケーション１３０において使用するために、公開してもよく、これも永続的な保存を含意する。
・登録は、現在のアプリケーションのライフサイクルの間のみ、一時的に保存してもよい。
【０１３５】
アプリケーション１３０は、インスタンスの各ｇｅｔＴｙｐｅ（）メソッドを呼び出して、返された値の同一性を比較することにより、パーサ１１２及びファクトリ１１４の一致する対をインスタンス化しているか否かを確認してもよい。アプリケーション１３０が一致しないパーサ１１２及びファクトリ１１４の対を使用すると、予測できない結果が生じる虞があり、若しくは、未定義の又は誤った振る舞いを引き起こす可能性がある。
【０１３６】
以下では、この依存関係を簡潔に説明する。
・ＩＦ２オブジェクトモデル：これは、パーサ１１２の実際のインプリメンテーションが満たすべき暗黙の依存関係にすぎない。通常、ファクトリ１１４が入力データとしてｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔインスタンスを単に予期するという事実によって、この依存関係は排除される。しかしながら、作成処理に実際に渡される特別に構成されたシステムにおいては、Ｅ２ＥＮＰ  ＵＡ１２８では、特定のオブジェクモデルクラスのインスタンスが用いられる。
・トランスポート表現：勿論、上述の依存関係と同様に、実際のファクトリ１１４は、自らが作成しなくてはならないシステムに関する明確な構造を必要とする。したがって、これは、トランスポート表現のそれぞれの定義に依存する。但し、通常は、ｊａｖａ．ｉｏ．Ｓｅｒｉａｌｉｚａｂｌｅを用いてトランスポート表現を抽象的に記述することによって、この依存関係は、設計から排除される。
【０１３７】
ＴＡＢ９は、ファクトリＡＰＩ１０１ｅによってインプリメントすべきプリミティブを列挙している。更に、ＴＡＢ１０は、特定のファクトリ１１４を生成するためにインプリメントすべきプリミティブを示している。
【０１３８】
ＰａｒｓｅｒＦａｃｔｏｒｙ  ＡＰＩは、ファクトリ−ファクトリインプリメンテーションとも呼ばれるパッケージｏｒｇ．ｍｉｎｄ．ｅ２ｅｎｐ．ｃｏｎｔｅｎｔのクラスＥ２ＥＮＰＣｏｎｔｅｎｔ−ＨａｎｄｌｅｒＦａｃｔｏｒｙによって実現される。このクラスは、全てのクライアントが先に作成された登録を使用できるように単集合インスタンスとして設計される。現在作成されている単集合インスタンスは、初期的なインプリメンテーションであるが、将来的には、単集合インスタンスのために用いられるクラスを決定するために、（例えば、特定のシステムプロパティに基づいて）構成可能な手法を提供することが計画されている。ＴＡＢ１１は、Ｅ２ＥＮＰ−ＣｏｎｔｅｎｔＨａｎｄｌｅｒＦａｃｔｏｒｙクラスによって提供される処理を示している。
【０１３９】
以下のサブセクションでは、ＸＭＬベースのトランスポート表現のためのファクトリ１１４のインプリメンテーションを簡潔に説明する。
【０１４０】
パーサ１１２の場合と同様、ファクトリ１１４のインプリメントにおいても、［Ｇａｍ］に開示されている「ビジター設計パターン（visitor design pattern）」を用いる。この構造を図２０に示す。
【０１４１】
ここでも、１〜ＮのＯｂｊｅｃｔＧｒａｐｈＮｏｄｅ２００４クラスを訪れるジェネリックファクトリ１１４ビジタークラスｆＶｉｓｉｔｏｒ２００２が定義される。ＯｂｊｅｃｔＧｒａｐｈＮｏｄｅの各具体的なサブクラス毎に、対応する具体的なビジタークラスが定義される。
【０１４２】
以下のサブセクションでは、ＳＩＰユーザエージェントジェネリックＡＰＩ１０１ｃ（ＩＦ３）の概要を簡潔に説明する。
【０１４３】
ＳＩＰユーザエージェントジェネリックＡＰＩ１０１ｃは、ジェネリックＳＩＰ  ＵＡ１１０の機能をＥ２ＥＮＰ  ＵＡ１２８に提供するため、このＡＰＩの主な目的は、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６からＳＩＰ  ＵＡ１１０の実際のインプリメンテーションをマスクすることである。ＳＩＰユーザエージェントジェネリックＡＰＩ１０１ｃは、一組のインタフェース及びＡＰＩを介して交換される複合データタイプを定義することによって、このようなジェネリックＡＰＩの仕様を実現する。特定のＳＩＰ  ＵＡ１１０インプリメンテーションは、ＳＩＰ  ＡＰＩ固有のインタフェースをＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃにマッピングし、及びこれと逆のマッピングを行う特定のアダプタによって、それらの固有（最終的には標準）のＡＰＩを提供する。
【０１４４】
ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃにより、複数のユーザは、同時に、（マルチメディアアプリケーション１３０又はミドルウェア１３０を介して）所定のＳＩＰ  ＵＡ１１０インプリメンテーションにアクセスし、同時に複数のＳＩＰセッションを確立することができる。
【０１４５】
また、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、これらのエンティティによって必要とされるＳＩＰシグナリングによってＳＩＰレジストラインプリメンテーションをサポートする。但し、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、同じメモリアドレス空間において、ユーザアプリケーション１３０とＳＩＰレジストラを同時にサポートするようには設計されていない。この設計を選択することにより、ＳＩＰレジストラインプリメンテーションは、純粋なアプリケーション１３０又はミドルウェア１３０エンティティ（このコンテキストでは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６）とは異なるスタンドアロンサーバ側のエンティティとして実現することが必要となる。アプリケーション１３０ミドルウェア１３０（このコンテキストでは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６）及びＳＩＰレジストラインプリメンテーションは、サービスユーザの具体例である。ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃを提供するＳＩＰ  ＵＡ１１０インプリメンテーションは、サービスプロバイダを表す。
【０１４６】
ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、本来、特定のオープンソースＳＩＰ  ＵＡ１１０インプリメンテーションからＡＰＩを提供するために設計されており（Mitre's JSIP v0.8 library (http://jsip.sourceforge.net/)）、ＡＰＩサポート能力は極めて低い。ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、以下の設計原理に基づいて設計されている。
１．様々なＳＩＰ手続を特定する一組のプリミティブの定義を比較的ハイレベルに抽象化し、これにより、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６設計を単純化する。勿論ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの現在のバージョンによって提供される手続の精度は、ＪａｖａベースのＳＩＰインプリメンテーションの能力をある程度反映する。他のＳＩＰ  ＵＡ１１０インプリメンテーションは、上述した対応するアダプタに埋め込まれた何らかのロジックが必要とする何らかの能力を提供できる場合がある。
２．ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの現在のバージョンは、Ｅ２ＥＮＰ  ＵＡ１２８のプロトタイピング及び検査に必要な最小限の機能のセットのみに照準を合わせている。したがって、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの現在のバージョンは、完全なＳＩＰ  ＡＰＩ仕様を目的としておらず、標準化を意図するものでもない。
【０１４７】
３．プリミティブは、ＩＳＯ／ＯＳＩモデルに基づいて要求（Ｒｅｑ）プリミティブ、指示（Ｉｎｄ）プリミティブ、応答（Ｒｓｐ）プリミティブ及び確認（Ｃｆｍ）プリミティブに分類される。要求（Ｒｅｑ）プリミティブ及び応答（Ｒｓｐ）プリミティブは、特定のメッセージ交換を開始し、又はこれに応じるために、ＩＦ３１０１ｃのクライアントサービスユーザ又はＳＩＰレジストラインプリメンテーションによって呼び出される。（幾つかの場合、メッセージ交換は、所定のＳＩＰ  ＵＡ１１０インプリメンテーションによって実現される抽象化により、ピア間で交換される一組の異なるメッセージを含むことができ、この他の場合、メッセージ交換は、所定のメッセージとその承認に制限される）。指示（Ｉｎｄ）プリミティブ及び確認（Ｃｆｍ）プリミティブは、特定の各メッセージ交換の到着を示し、又は所定のメッセージ交換の結果を確認するために、サービスプロバイダ１１０によって、ＩＦ３１０１ｃのサービスユーザの登録されたクライアント側に呼び出される。ＩＦ３１０１ｃのサービスユーザのクライアント側は、これらのプリミティブをインプリメントする必要がある。所定のプロトコルメッセージ交換を開始するピアによって生成された要求プリミティブには、ターゲットピアにおける指示（Ｉｎｄ）プリミティブが対応する。所定のプロトコルメッセージ交換に応じるターゲットピアによって生成された応答（Ｒｓｐ）プリミティブには、開始側ピアにおける確認（Ｃｆｍ）プリミティブが対応する。
４．［Ｇａｍ］に開示されている「オブザーバ設計パターン」の簡易型のバージョン（Ｊａｖａ  Ｂｅａｎｓイベントモデルの派生モデルとして、Ｊａｖａによってインプリメントされる）は、サービスユーザが（「バインド要求」と呼ばれるプリミティブを介して）指示（Ｉｎｄ）及び／又は確認（Ｃｆｍ）プリミティブコールバックへの登録するためのメカニズムを提供する。
５．ＳＩＰを介するＥ２ＥＮＰのピギーバッキングをサポートするために、各プリミティブは、例えば、ＳＤＰ、ＳＤＰｎｇ又は多目的インターネットメールエクステンション（Multipurpose Internet Mail Extension：ＭＩＭＥ）コンテンツ等のペイロードを渡すことができる。
６．実際のＳＩＰ  ＵＡ１１０インプリメンテーション及びＳＤＰ／ＳＤＰｎｇパーサ１１２及び／又はファクトリ１１４のサポートなしでＥ２ＥＮＰシグナリングロジックのドライ−ラン検査を可能にするために、プリミティブは、（ＡＳＣＩＩ文字列を表す明瞭なオブジェクトに代えて）、Ｊａｖａシリアル化又は逆シリアル化等のリモートプロシージャコール（ＲＰＣ）メカニズムをＪａｖａ  ＲＭＩと組み合わせて用いた場合にマーシャリング又はデマーシャリングできるジェネリックオブジェクトとしてペイロードを扱うよう設計される。
７．ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃを設計するために用いられたＭｉｔｒｅのＪＳＩＰバージョン０．８は、通常、サービスユーザによって操作されるＳＩＰ有効期間ヘッダフィールド（SIP Expires header field）を正しくサポートしてないため、このＳＩＰヘッダフィールドは、フィールドのあらゆる種類のインプリメンテーションに対応できるよう抽象化されている。これは、設計者がＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃを（したがって、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６インプリメンテーションを）必要に応じて変更でき、又は（Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６インプリメンテーションを変更することなく）所定のサービスプロバイダの有効期間ヘッダフィールドサポートをマッピングするアダプタ１２６ｃを提供できる他の柔軟なＳＩＰ  ＵＡ１１０インプリメンテーションでは不要である。
【０１４８】
更なる設計の選択肢は、以下の通りである。
・［ＲｅｑＳｐｅｃ］に開示されているＥ２ＥＮＰ交渉モデルは、Ｅ２ＥＮＰの主な側面であり、ＳＤＰｎｇペイロードに埋め込まれ、エンドツーエンドベースでピア間で交換されることを意図された情報である。Ｅ２ＥＮＰ  ＵＡ１２８を速やかにプロトタイピングするために、Ｅ２ＥＮＰ交渉モデル情報を表すＳｉｐＮｅｇｏｔｉａｔｉｏｎＭｏｄｅｌ２２１６と名付けられたヘルパクラス（helper class）をＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃに臨時に含める。
・アプリケーションレベルにおいて唯一の有効なセッションを特定することに代えて、英数字のＳＩＰ呼び出し識別子ヘッダフィールドを用いることによって、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、ｃｏｎｎｅｃｔｉｏｎＩｄと呼ばれる数字のみによる整数識別子を用いる。この選択肢は、以下の理由により採用される。
【０１４９】
−サービスユーザは、英数字の識別子より、数字のみの識別子によって、より容易にリストを扱うことができる。
【０１５０】
−Ｅ２ＥＮＰ  ＵＡ１２８が、将来、ＳＩＰに代えて、他のプロトコルを用いた場合、ジェネリックプリミティブ及びジェネリックセッション識別子を使用している方が、既存のＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６設計の再使用を実現しやすい。
【０１５１】
ＳＩＰ  ＵＡ１１０は、入力されるＩＮＶＩＴＥメソッド、ＯＰＴＩＯＮＳメソッド、ＭＥＳＳＡＧＥメソッド又はＲＥＧＩＳＴＥＲメソッドのＳＩＰ呼び出し識別子ヘッダフィールドにｃｏｎｎｅｃｔｉｏｎＩｄの未使用の値を関連付ける。同じ設計原理を適用することによって、これらのメソッドの何れかを要求するサービスユーザは、元の要求（Ｒｅｑ）プリミティブに関連している確認（Ｃｆｍ）プリミティブのサービスプロバイダによって選択されたｃｏｎｎｅｃｔｉｏｎＩｄ値を入手する。
【０１５２】
残念ながら、このソリューションは、以下のような２つの問題がある。
１．所定の要求（Ｒｅｑ）プリミティブに関連するｃｏｎｎｅｃｔｉｏｎＩｄ値に関する情報がなければ、サービスユーザは、対応する要求（Ｒｅｑ）プリミティブを確認（Ｃｆｍ）プリミティブに関連付けることができない。
２．確認（Ｃｆｍ）プリミティブの到着に、中間的メッセージ（最終的に障害状況を示す）更なるプリミティブ（例えば、接続状態表示）が生成されることもあり、これは、先に指摘した点と同様の相関問題を引き起こす。
【０１５３】
これらの問題を解決するために、サービスユーザは、未使用のｃｏｎｎｅｃｔｉｏｎＩｄ値を選択し、ＳＩＰ  ＵＡ１１０を、強制的に、適切なＳＩＰ呼び出し識別子ヘッダフィールド値を有するこの値に関連付ける必要がある。
【０１５４】
入力されるＩＮＶＩＴＥメソッド、ＯＰＴＩＯＮＳメソッド、ＭＥＳＳＡＧＥメソッド又はＲＥＧＩＳＴＥＲメソッドの場合、サービスプロバイダによって割り当てられ、出力されるＩＮＶＩＴＥメソッド、ＯＰＴＩＯＮＳメソッド、ＭＥＳＳＡＧＥメソッド又はＲＥＧＩＳＴＥＲメソッドの場合、サービスユーザによって割り当てられるｃｏｎｎｅｃｔｉｏｎＩｄ値のセットは、入力及び出力されるＩＮＶＩＴＥメソッド、ＯＰＴＩＯＮＳメソッド、ＭＥＳＳＡＧＥメソッド又はＲＥＧＩＳＴＥＲメソッドの処理が、同時に、互いに干渉せずに実行されるように、区別する必要がある。
【０１５５】
但し、構造を簡潔にするために、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、サービスプロバイダ自体に埋め込まれ、ｃｏｎｎｅｃｔｉｏｎＩｄ値の割り当てを集中的に管理するよう設計されている。なお、サービスユーザは、出力されるＩＮＶＩＴＥメソッド、ＯＰＴＩＯＮＳメソッド、ＭＥＳＳＡＧＥメソッド又はＲＥＧＩＳＴＥＲメソッドについて、ｃｏｎｎｅｃｔｉｏｎＩｄ値を割り当てる役割を担っているが、実際の割り当ては、サービスプロバイダによって提供されるｇｅｔＣｏｎｎｅｃｔｉｏｎＩｄ（）処理を呼び出すことによって、サービスプロバイダに代理させる。このメソッドは、値（選択されたｃｏｎｎｅｃｔｉｏｎＩｄ値）を直接返すのでプリミティブ自体であるとみなすことはできない。例えば、これは、（ＲＰＣとは異なる）メッセージベースのプロトコルを介してプリミティブがサービスユーザとサービスプロバイダの間で交換される疎結合インタフェースをインプリメントする妨げとなる。何れの場合も、サービスユーザ及びサービスプロバイダは、それぞれ単にｇｅｔＣｏｎｎｅｃｔｉｏｎＩｄメソッドを用いないことによって、集中型のｃｏｎｎｅｃｔｉｏｎＩｄ値割り当て管理なしで、且つ、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃに準拠するように設計することできる。特別な状況では、ＳＩＰｒｅ−ＩＮＶＩＴＥの場合、ｃｏｎｎｅｃｔｉｏｎＩｄを再利用できる。この場合、これがｒｅ−ＩＮＶＩＴＥであるか否かを示す適切なブールパラメータがｃｏｎｎｅｃｔｉｏｎＲｅｑプリミティブに渡される（後述の説明参照）。
・以下に示すＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの幾つかのプリミティブは、ＳＩＰ固有である。
−ＰＲＡＣＫメソッドをインプリメントするために用いられるｐｒｏｖｉｓｉｏｎａｌＡｃｋ（Ｒｅｑ｜Ｉｎｄ｜Ｒｓｐ｜Ｃｆｍ）。
−ＲＥＧＩＳＴＥＲメソッドをインプリメントするために用いられるｒｅｇｉｓｔｅｒ（Ｒｅｑ｜Ｉｎｄ｜Ｒｓｐ｜Ｃｆｍ）。
−ＯＰＴＩＯＮＳメソッドをインプリメントするために用いられるｏｐｔｉｏｎｓ（Ｒｅｑ｜Ｉｎｄ｜Ｒｓｐ｜Ｃｆｍ）。
−ＭＥＳＳＡＧＥメソッドをインプリメントするために用いられるｍｅｓｓａｇｅ（Ｒｅｑ｜Ｉｎｄ｜Ｒｓｐ｜Ｃｆｍ）。
【０１５６】
これらのプリミティブは、最終的に、将来のＥ２ＥＮＰ  ＵＡ１２８の設計において、よりジェネリックなプリミティブにマッピングされ、これによりＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、実際に用いられるセッションレイヤプロトコルから完全に独立したＥ２ＥＮＰセッションレベルプロトコルＡＰＩに変換される。
・ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ設計の現在のバージョンは、［Ｒｏｓ１］に開示されているＳＩＰ仕様の（現時点における）最新の動作中のバージョンに、部分的に準拠しているのみである。例えば、ＲＥＦＥＲ、ＤＯ、ＮＯＴＩＦＹ、ＳＵＢＳＣＲＩＢＥメソッドと、この他の多くの特徴は、Ｅ２ＥＮＰ概念を検査するためには不要であるため、省略されている。ＢＹＥ及びＣＡＮＣＥＬメソッドは、同じ切断（Disconnection）プリミティブによってサポートされる。
【０１５７】
このように、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂは、指示（Ｉｎｄ）及び確認（Ｃｆｍ）プリミティブのインプリメンテーション及び基本的なＳＩＰ  ＵＡ１１０を構成し、制御し、リセットするために用いられる管理コンポーネント１０２に関して適用されたＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６に依存する。
【０１５８】
ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、オブジェクト指向パラダイムを用いて設計され、したがって、ここでは、統一モデリング言語（ＵＭＬ）を用いて記述される。ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃは、基本的なパッケージ、すなわち図２１に示すような、所謂ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉで構成される。この基本的なパッケージは、クラスＳｉｐＥｎｄＵｓｅｒ２２１４とＳｉｐＥｘｐｉｒｅｓＨａｎｄｌｉｎｇ２１１２を含む。ＳｉｐＥｎｄＵｓｅｒクラス２２１４は、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃによって提供されるＳＩＰサービスにアクセスするユーザを表す。ＳｉｐＥｘｐｉｒｅｓＨａｎｄｌｉｎｇクラスは、ＳＩＰ有効期間ヘッダフィールドを操作する機能を般化する。ＳｉｐＬｉｓｔｅｎｅｒ２１０８は、サービスユーザが、ＳＩＰ  ＵＡ１１０によって生成された指示（Ｉｎｄ）及び／又は確認（Ｃｆｍ）プリミティブの割込をインプリメントする全てのインタフェースを般化する。ＳｉｐＰｒｏｖｉｄｅｒ２１１０は、サービスプロバイダが、要求（Ｒｅｑ）及び応答（Ｒｓｐ）プリミティブのインプリメントをサポートする全てのインタフェースを般化する。
【０１５９】
ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの仕様は、４つのサブパッケージから構成される。そのうちの１つであるｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｔｉｍｅは、ＳＩＰ有効期間ヘッダフィールドの抽象化を取り扱うものであり、他の３つは、以下のようにサービスユーザの異なる役割を特徴付ける。
・ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｕｓｅｒＡｇｅｎｔは、アプリケーション１３０／ミドルウェア１３０インプリメンテーション（このコンテキストではＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６）を表す。
・ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｍａｎａｇｅｍｅｎｔは、管理エンティティ１０２を表す。
・ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｒｅｇｉｓｔｒａｒは、ＳＩＰレジストラインプリメンテーション２３０６を表す。
【０１６０】
ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｕｓｅｒＡｇｅｎｔサブパッケージ（図２２参照）は、ＩＦ３１０１ｃ（このコンテキストにおけるＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６）のサービスユーザがサービスプロバイダにアクセスするために用いるＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの部分を指定するインタフェース及びクラスを含んでいる。これは、以下のような３つの主要な部分からなる。
１．ＩＦ３  １０１ｃのサービスユーザが、サービスプロバイダ１１０によって生成される指示及び／又は確認（Ｃｆｍ）プリミティブの割込をインプリメントするインタフェース。
・ＳｉｐＵｓｅｒＡｇｅｎｔＬｉｓｔｅｎｅｒ２２０２：クライアント側とサーバ側の両方に共通；ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ＳｉｐＬｉｓｔｅｎｅｒインタフェース２１０８の特化。
・ＳｉｐＵｓｅｒＡｇｅｎｔＣｌｉｅｎｔＬｉｓｔｅｎｅｒ２２０６：クライアント側に固有；ＳｉｐＵｓｅｒＡｇｅｎｔＬｉｓｔｅｎｅｒインタフェース２２０２の特化。
・ＳｉｐＵｓｅｒＡｇｅｎｔＳｅｒｖｅｒＬｉｓｔｅｎｅｒ２２０４：サーバ側に固有；ＳｉｐＵｓｅｒＡｇｅｎｔＬｉｓｔｅｎｅｒインタフェース２２０２の特化。
２．特定のプリミティブのためのクラスバンドリングパラメータ（現在、接続要求（Ｒｅｑ）プリミティブのためのＳｉｐＣｏｎｎｅｃｔｉｏｎＲｅｑクラス２２０８、登録要求（Ｒｅｑ）プリミティブのためのＳｉｐＲｅｇｉｓｔｒａｔｉｏｎＲｅｑクラス２２１８、及び登録確認（Ｃｆｍ）プリミティブのためのＳｉｐＲｅｇｉｓｔｒａｔｉｏｎＣｆｍクラス２２２０のみ）。これらのクラスのインスタンスは、プリミティブをインプリメントするモジュールに所定のプリミティブのパラメータとして渡される。このソリューションにより、プリミティブシグネチャに影響を与えることなくＡＰＩの詳細を拡張及び／又は変更することができる。
３．ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のためにサービスプロバイダがサポートするＡＰＩを指定するインタフェース及びクラス。ＳｉｐＵｓｅｒＡｇｅｎｔＴｙｐｅインタフェース２２１０は、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のために、基底にあるＳＩＰ  ＵＡ１１０インプリメンテーションがサポートする要求（Ｒｅｑ）及び応答（Ｒｓｐ）プリミティブのセットを指定する。ＳｉｐＵｓｅｒＡｇｅｎｔＴｙｐｅインタフェース２２１０は、以下に示すインタフェースを特化したものである。
ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ＳｉｐＰｒｏｖｉｄｅｒ
ＳｉｐＵｓｅｒＡｇｅｎｔクラス２２１４は、［Ｇａｍ］に開示されている「抽象化ファクトリ」及び「単集合」設計パターンを適用することによってＳｉｐＵｓｅｒＡｇｅｎｔＴｙｐｅインタフェース２２１０のあらゆるインプリメンテーションをラッピングする。「抽象化ファクトリ」は、ＳｉｐＵｓｅｒＡｇｅｎｔＦａｃｔｏｒｙインタフェース２２１２によって定義される。ＳｉｐＵｓｅｒＡｇｅｎｔクラス２２１４は、デフォルトインプリメンテーションの完全に修飾された（省略がない）クラス名を有するｄｅｆＩｍｐｌクラス属性を用いることによって、デフォルトインプリメンテーションを用いるよう設計される。上述したＳｉｐＵｓｅｒＡｇｅｎｔＴｙｐｅインタフェース２２１０のカスタムインプリメンテーションは、上述したＳｉｐＵｓｅｒＡｇｅｎｔＦａｃｔｏｒｙインタフェース２２１２をインプリメントする特定のファクトリクラスを提供することによって作成できる。ＳｉｐＵｓｅｒＡｇｅｎｔクラス２２１４は、所定のカスタムファクトリの単集合インスタンスを保存するｓｅｔＵｓｅｒＡｇｅｎｔＦａｃｔｏｒｙ（）と呼ばれるクラスメソッドを提供する。
【０１６１】
そして、このサブパッケージは、Ｅ２ＥＮＰ交渉モデルを表すＳｉｐＮｅｇｏｔｉａｔｉｏｎＭｏｄｅｌという名のクラス２２１６を含んでいる。
【０１６２】
ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｒｅｇｉｓｔｒａｒサブパッケージ（図２３）は、ＳＩＰレジストラインプリメンテーションがサービスプロバイダにアクセスするために用いたＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの部分を指定するインタフェース及びクラスを含んでいる。これは、以下のような３つの主要な部分からなる。
１．ＩＦ３  １０１ｃのサービスユーザが、サービスプロバイダ１１０によって生成される指示及び／又は確認（Ｃｆｍ）プリミティブの割込をインプリメントするインタフェース。
・ＳｉｐＲｅｇｉｓｔｒａｒＬｉｓｔｅｎｅｒ  ２３０２：クライアント側とサーバ側の両方に共通；ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ＳｉｐＬｉｓｔｅｎｅｒインタフェース２１０８の特化。
２．特定のプリミティブのためのクラスバンドリングパラメータ（現在、登録指示（Ｉｎｄ）プリミティブのためのＳｉｐＲｅｇｉｓｔｒａｔｉｏｎＩｎｄクラス２３０８及び登録応答（Ｒｓｐ）プリミティブのためのＳｉｐＲｅｇｉｓｔｒａｔｉｏｎＲｓｐクラス２３１０のみ）。これらのクラスのインスタンスは、プリミティブをインプリメントするモジュールに所定のプリミティブのパラメータとして渡される。このソリューションにより、プリミティブシグネチャに影響を与えることなくＡＰＩの詳細を拡張及び／又は変更することができる。
３．ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のためにサービスプロバイダ１１０がサポートするＡＰＩを指定するインタフェース及びクラス。ＳｉｐＲｅｇｉｓｔｒａｒＴｙｐｅインタフェース２３０４は、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のために、基底にあるＳＩＰ  ＵＡ１１０インプリメンテーションがサポートする要求（Ｒｅｑ）及び応答（Ｒｓｐ）プリミティブのセットを指定する。ＳｉｐＲｅｇｉｓｔｒａｒＴｙｐｅインタフェース２３０４は、以下に示すインタフェース２１１０を特化したものである。
ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ＳｉｐＰｒｏｖｉｄｅｒ
ＳｉｐＲｅｇｉｓｔｒａｒ  ｃｌａｓｓ  ２３０６は、［Ｇａｍ］に開示されている「抽象化ファクトリ」及び「単集合」設計パターンを適用することによってＳｉｐＲｅｇｉｓｔｒａｒＴｙｐｅインタフェース２３０４のあらゆるインプリメンテーションをラッピングする。「抽象化ファクトリ」は、ＳｉｐＲｅｇｉｓｔｒａｒＦａｃｔｏｒｙインタフェース２３１２によって定義される。ＳｉｐＲｅｇｉｓｔｒａｒクラス２３０６は、デフォルトインプリメンテーションの完全に修飾された（省略がない）クラス名を有するｄｅｆＩｍｐｌクラス属性を用いることによって、デフォルトインプリメンテーションを用いるよう設計される。上述したＳｉｐＲｅｇｉｓｔｒａｒＴｙｐｅインタフェース２３０４のカスタムインプリメンテーションは、上述したＳｉｐＲｅｇｉｓｔｒａｒＦａｃｔｏｒｙインタフェース２３１２をインプリメントする特定のファクトリクラスを提供することによって作成できる。ＳｉｐＲｅｇｉｓｔｒａｒクラス２３０６は、所定のカスタムファクトリの単集合インスタンスを保存するｓｅｔＲｅｇｉｓｔｒａｒＦａｃｔｏｒｙ（）と呼ばれるクラスメソッドを提供する。
【０１６３】
ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｍａｎａｇｅｍｅｎｔサブパッケージ（図２４参照）は、サービスプロバイダを構成し、制御する管理エンティティ１０２に適用されるＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの部分を指定するインタフェース及びクラスを含んでいる。これは、以下のような３つの主要な部分からなる。
１．サービスユーザが、サービスプロバイダによって生成される指示及び／又は確認（Ｃｆｍ）プリミティブの割込をインプリメントする以下のインタフェース。
ＳｉｐＭａｎａｇｅｍｅｎｔＬｉｓｔｅｎｅｒ
２．特定のプリミティブのためのクラスバンドリングパラメータ（現在、構成要求（Ｒｅｑ）プリミティブのためのＳｉｐＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｑクラス２４０６のみ）。これらのクラスのインスタンスは、プリミティブをインプリメントするモジュールに所定のプリミティブのパラメータとして渡される。このソリューションにより、プリミティブシグネチャに影響を与えることなくＡＰＩの詳細を拡張及び／又は変更することができる。
３．ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のためにサービスプロバイダがサポートするＡＰＩを指定するインタフェース。ＳｉｐＭａｎａｇｅｒインタフェース２４０４は、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のために、基底にあるＳＩＰ  ＵＡ１１０インプリメンテーションがサポートする要求（Ｒｅｑ）及び応答（Ｒｓｐ）プリミティブのセットを指定する。
【０１６４】
ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｔｉｍｅサブパッケージ（図２５参照）は、サービスユーザがＳＩＰ有効期間ヘッダフィールドを操作するためのＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの部分を指定するインタフェース及びクラスを含んでいる。これは、以下のような２つの主要な部分からなる。
１．ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のためにサービスプロバイダがサポートするＡＰＩを指定するインタフェース及びクラス。ＳｉｐＥｘｐｉｒｅｓＴｙｐｅインタフェース２５０２は、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃとの互換性のために、基底にあるＳＩＰ  ＵＡ１１０インプリメンテーションがサポートするＳＩＰ有効期限ヘッダフィールド操作処理のセットを指定する。ＳｉｐＥｘｐｉｒｅｓクラス２５０６は、［Ｇａｍ］に開示されている「抽象化ファクトリ」及び「単集合」設計パターンを適用することによってＳｉｐＥｘｐｉｒｅｓＴｙｐｅインタフェース２５０２のあらゆるインプリメンテーションをラッピングする。「抽象化ファクトリ」は、ＳｉｐＥｘｐｉｒｅｓＦａｃｔｏｒｙインタフェース２５０８によって定義される。ＳｉｐＥｘｐｉｒｅｓクラス２５０６は、デフォルトインプリメンテーションの完全に修飾された（省略がない）クラス名を有するｄｅｆＩｍｐｌクラス属性を用いることによって、デフォルトインプリメンテーションを用いるよう設計される。上述したＳｉｐＥｘｐｉｒｅｓＴｙｐｅインタフェース２５０２のカスタムインプリメンテーションは、上述したＳｉｐＥｘｐｉｒｅｓＦａｃｔｏｒｙインタフェース２５０８をインプリメントする特定のファクトリクラスを提供することによって作成できる。ＳｉｐＥｘｐｉｒｅｓクラス２５０６は、所定のカスタムファクトリの単集合インスタンスを保存するｓｅｔＳｉｐＥｘｐｉｒｅｓＦａｃｔｏｒｙ（）と呼ばれるクラスメソッドを提供する。
２．ＳｉｐＰａｒｓｅＥｘｃｅｐｔｉｏｎクラス２５０４は、規則に違反する統語構造のために、ＳＩＰ有効期間ヘッダフィールドの解析が失敗した場合に、サービスプロバイダによって生じる例外を表す。
【０１６５】
以下のサブセクションでは、一組のＵＭＬメッセージシーケンス図（ＭＳＣ）を用いて、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃによって可能にされた手続を記述する。
【０１６６】
図２６は、サービスプロバイダ１１０の構成及びＩＦ３１０１ｃのサービスユーザがサービスユーザとして、そのクライアントとサーバサブユニットをどのように作成し、サービスプロバイダ１１０に結合（bind）するかを示している。図２７は、［Ｒｏｓ１］に開示されている手続に基づいて、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃを介してＳＩＰセッションをどのように確立することができるかを示している。この手続は、呼出パーティ（又はイニシエータ）として機能するピアによって呼び出されたｃｏｎｎｅｃｔｉｏｎＲｅｑプリミティブから開始され、メッセージ交換をトリガし、被呼出パーティ（又はレスポンダ）として機能するピアが、最初にイニシエータによるＳＩＰセッションを確立するための招待を通知するｃｏｎｎｅｃｔｉｏｎＩｎｄプリミティブを受け取った後に、（複数の交渉及びシグナリングステップを経て）最終的にこの招待に応じ、ｃｏｎｎｅｃｔｉｏｎＲｓｐプリミティブによって応答した場合にのみ終了する。
【０１６７】
レスポンダは、イニシエータ側においてｃｏｎｎｅｃｔｉｏｎＳｔａｔｕｓＩｎｄプリミティブ呼出にマッピングされるｃｏｎｎｅｃｔｉｏｎＳｔａｔｕｓＲｅｑプリミティブの呼出を介して、ＳＩＰ暫定応答を生成する。イニシエータは、レスポンダ側において、それぞれＰｒｏｖｉｓｉｏｎａｌＡｃｋＩｎｄ／Ｒｓｐプリミティブに対応する、ＰｒｏｖｉｓｉｏｎａｌＡｃｋＲｅｑ／Ｃｆｍプリミティブを用いることによって、ＰＲＡＣＫメソッドによりこの暫定応答を承認する。
【０１６８】
この手続は、イニシエータがｃｏｎｎｅｃｔｉｏｎＣｆｍプリミティブを受け取り、レスポンダがｃｏｎｎｅｃｔｉｏｎＳｔａｔｕｓＩｎｄプリミティブを受け取ることによって終了する。後者の理由は、［Ｒｏｓ１］に開示されているＳＩＰの３方向の承認スキーム（three-way acknowledgment scheme）のためである。
【０１６９】
このＭＳＣにおける２つの手続、すなわち、レスポンダ側における「１００  Ｔｒｙｉｎｇ」暫定応答の生成及びイニシエータ側における最終的なＡＣＫ信号の生成は、サービスプロバイダによって自動的に実行されると考えられる。但し、イニシエータ側における最終的なＡＣＫ信号の生成は、ｃｏｎｎｅｃｔｉｏｎＳｔａｔｕｓＲｓｐプリミティブを介して、サービスユーザ自体によって強制されることもあるが、これは、ＡＣＫ信号を自動的に生成しないようにサービスユーザを構成する必要があることを意味する。
【０１７０】
成功以外の理由を示す最終的なＳＩＰ応答は、サービスプロバイダによって自動的に、又はｃｏｎｎｅｃｔｉｏｎＳｔａｔｕｓＲｅｑプリミティブを介して、レスポンダのサービスユーザによって明示的に生成される。これらのＳＩＰ応答は、ｃｏｎｎｅｃｔｉｏｎＳｔａｔｕｓＩｎｄプリミティブを介して、イニシエータのサービスユーザに通知される。
【０１７１】
図２８は、ＯＰＴＩＯＮＳメソッドがｏｐｔｉｏｎｓＲｅｑ｜Ｉｎｄ｜Ｒｓｐ｜Ｃｆｍプリミティブを介して、どのように扱われるかを示している。図２９は、ＳＩＰセッションがｄｉｓｃｏｎｎｅｃｔｉｏｎＲｅｑ｜Ｉｎｄ｜Ｒｓｐ｜Ｃｆｍプリミティブを介して、どのようにを解放されるかを示している。このＭＳＣは、ＢＹＥのケースを示しているが接続確立の間に呼び出された同じ手続は、ＣＡＮＣＥＬを生成する。
【０１７２】
以下のサブセクションでは、Ｅ２ＥＮＰ  ＵＡ１２８に適用された有限状態マシン１０６（ＦＳＭ）を簡潔に説明する。
【０１７３】
Ｅ２ＥＮＰ  ＵＡ１２８のコアは、総合的な機能を調整し、上述のインタフェースの一部をインプリメントする有限状態マシン１０６（ＦＳＭ）から構成される。詳しくは、ＦＳＭ１０６は、ＩＦ３、ＩＦ４及びＩＦ５のサービスユーザ部分と、ＩＦ１とＩＦ２のサービスプロバイダ部分とをインプリメントする。更に、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、上述したキャッシュ１０４を利用する。
【０１７４】
ＦＳＭ１０６は、ＳｔａｔｅＣｈａｒｔとして階層的に設計される。ルート状態（図３０参照）においては、ＦＳＭ１０６は、ローカルユーザ及びリモートユーザの何れかの決定に関連するセッション終了イベントを扱う。更に、ルート状態は、前交渉、リース更新、オファー側／アンサ側としての交渉、再交渉及びセッションの解放処理を扱う。なお、「交渉」処理という用語は、［ＲｅｑＳｐｅｃ］に開示されているリソース予約調整とＱｏＳ交渉に関連するマルチメディアセッション確立を示すために用いられる。
【０１７５】
オファー側の役割は、ＱｏＳ交渉及びリソース予約によってセッション確立を開始するピアが担うが、再交渉を開始することを決定するピアも、この役割を担う。一方、アンサ側の役割は、ＱｏＳ交渉とリソース予約によりセッション確立処理を行うための招待に応じるピアが担うが、再交渉を行うための招待に応じるピアも、この役割を担う。これは、当初オファー側の役割を担っていたピアが、後に、再交渉の際には、オファー側又はアンサ側の役割の何れを担ってもよいことを意味する。逆に、当初アンサ側の役割を担っていたピアが、後に、再交渉の際には、オファー側又はアンサ側の役割の何れを担ってもよい。
【０１７６】
図３０では、説明を簡潔にするために、ＩＦ１（管理ＡＰＩ）に関連するプリミティブの処理の詳細を示していない。すなわち、図３０では、ＦＳＭファクトリ１０６を有する内部インタフェースもキャッシュ１０４も考慮に入れられない。
【０１７７】
以下のサブセクションでは、図３０に示すミューテックスに関連する手続を詳細に説明する。
【０１７８】
オファー側／アンサ側としての交渉処理の低レベルの詳細は、ネスト構造のＦＳＭ１０６、すなわち、それぞれ、ＮｅｇＯｆｆｅｒｅｒサブ状態（図３１参照）及びＮｅｇＡｎｓｗｅｒｅｒサブ状態（図３２参照）にカプセル化される。
【０１７９】
ＮｅｇＯｆｆｅｒｅｒサブ状態は、オファー側の視点から見て、交渉処理を扱うロジックを捕捉するネスト構造のＦＳＭ１０６を含んでいる。ＮｅｇＡｎｓｗｅｒｅｒサブ状態は、アンサ側の視点から見て交渉処理を扱うロジックを捕捉するネスト構造のＦＳＭ１０６を含んでいる。
【０１８０】
一貫性を保証し、ローカルリソース、ピアのリソース及びネットワークリソースの結合された予約の間、［ＲｅｑＳｐｅｃ］に開示されているようなデッドロックを回避するために、ＮｅｇＯｆｆｅｒｅｒサブ状態とＮｅｇＡｎｓｗｅｒｅｒサブ状態においてネストされているＦＳＭ１０６は、システムワイドの「＿ＲｅｓｖＭｔｘ」ＦＳＭ１０６を用いて、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の他のインスタンスに関して互いに排他的に予約フェーズにアクセスする。「＿ＲｅｓｖＭｔｘ」ＦＳＭ１０６は、不可分（atomic）のローカルなメソッド呼出を介して（例えば、基本的なオペレーティングシステムによって提供される、何らかの特定のシステムコールを介して）、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の様々なインスタンスとインタラクトする。
【０１８１】
以下のサブセクションでは、図３１に示すミューテックスに関連する手続の詳細を説明する。
【０１８２】
オファー側／アンサ側としての再交渉処理の低レベルの詳細は、ネスト構造のＦＳＭ１０６、すなわち、それぞれ、ＲｅＮｅｇＯｆｆｅｒｅｒサブ状態（図３３参照）及びＲｅＮｅｇＡｎｓｗｅｒｅｒサブ状態（図３４参照）にカプセル化される。
・ＲｅＮｅｇＯｆｆｅｒｅｒサブ状態は、オファー側の視点から見て、再交渉処理を扱うロジックを捕捉するネスト構造のＦＳＭ１０６を含んでいる。
・ＲｅＮｅｇＡｎｓｗｅｒｅｒサブ状態は、アンサ側の視点から見て再交渉処理を扱うロジックを捕捉するネスト構造のＦＳＭ１０６を含んでいる。
【０１８３】
一貫性を保証し、ローカルリソース、ピアのリソース及びネットワークリソースの結合された予約の間、［ＲｅｑＳｐｅｃ］に開示されているようなデッドロックを回避するために、ＲｅＮｅｇＯｆｆｅｒｅｒサブ状態とＲｅＮｅｇＡｎｓｗｅｒｅｒサブ状態においてネストされているＦＳＭ１０６は、システムワイドの「＿ＲｅｓｖＭｔｘ」ＦＳＭ１０６を用いて、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の他のインスタンスに関して互いに排他的に予約フェーズにアクセスする。「＿ＲｅｓｖＭｔｘ」ＦＳＭ１０６は、不可分（atomic）のローカルなメソッド呼出を介して（例えば、基本的なオペレーティングシステムによって提供される、何らかの特定のシステムコールを介して）、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の様々なインスタンスとインタラクトする。
【０１８４】
以下のサブセクションでは、図３３に示すミューテックスに関連する手続を詳細に説明する。
【０１８５】
このメカニズムは、Ｅ２ＥＮＰ  ＵＡサービスユーザの同時に発生する様々なインスタンスを［ＲｅｑＳｐｅｃ］に開示されているように、リソース予約フェーズに互いに排他的にアクセスさせることによって、リソース予約フェーズのトランザクション的な処理を実施する。換言すればリソース予約ミューテックスにより、ローカルな承認制御と、最終的なネットワークリソース予約の間の段階をクリティカルセクションとして定義することができる。また、このメカニズムは、競合解決ポリシに組み合わされ、［ＲｅｑＳｐｅｃ］に開示されているデッドロック状況がＥ２ＥＮＰに影響しないことを保証する。
【０１８６】
同時に発生するＥ２ＥＮＰ  ＵＡサービスユーザインスタンスは、停止メソッドコール（suspensive method calls）を介して、ミューテックスを停止するよう試みる。ミューテックスを所有しているサービスユーザインスタンスは、シグナルコールイベントを介して、ミューテックスを解放する。
【０１８７】
「＿ＲｅｓｖＭｔｘ」は、プライオリティキューに関連付けられ、これにより、複数の要求がそれぞれの優先順位（図３５参照）に基づいて、連携して、ミューテックスを停止することができる。
【０１８８】
ミューテックスがアンロックされている場合は、如何なる要求も直ちに実現され、この他の場合、要求は、キューに送られる。優先順位が高い要求は、優先順位が低い要求より先に実現されるようにキューに送られる。同じ優先順位の要求は、「ファーストインファーストアウト（ＦＩＦＯ）」の順でキューに送られる。
【０１８９】
ミューテックスを取得するための全ての要求は、時間的に制限される。このような（構成可能な）期間が満了すると、ミューテックスについて保留中の所定のＥ２ＥＮＰ  ＵＡサービスユーザインスタンスは、失敗を示す戻り値によって再開される。
【０１９０】
この設計の選択により、ミューテックスを所有しているサービスユーザインスタンスが誤った振る舞いをしている（又は、ブロックされている）ときに生じる、ミューテックス上で保留中の同時に発生するＥ２ＥＮＰ  ＵＡサービスユーザインスタンスの飢餓状態を検出（したがって、防止）することができる。これは、特に、誤った振る舞いをするサービスユーザインスタンスが「＿ＲｅｓｖＭｔｘ」上に待機する、サービスユーザインスタンスの１つによって最終的に停止される他のアプリケーション固有のミューテックス、セマフォ又はロック上に保留されている場合、最も重要な点である。このような望ましくない状況では、事実上、デッドロックが不可避的に発生する。
【０１９１】
ブロックされた各要求に関する期限が経過すると、その要求（ｂｏｏｋＮｅｇｏｔｉａｔｉｏｎＲｅｑプリミティブ又はｂｏｏｋＲｅｎｅｇｏｔｉａｔｉｏｎＲｅｑプリミティブのパラメータリストにおいてそれぞれ特定される。ＴＡＢ１参照）の優先順位は、ミューテックスが与えられた要求の優先順位より高くなり、ミューテックスは、ミューテックスを所有しているサービスユーザインスタンスに関連しているＦＳＭ１０６ＵＡのインスタンスに、信号イベント、すなわちｃｏｎｇｅｓｔｉｏｎＩｎｄを送る。このイベントは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６ルート状態によって捉えられ、ミューテックスを所有しているサービスユーザインスタンスに送られたｆａｉｌｕｒｅＩｎｄプリミティブにマッピングされる。
【０１９２】
図３０に示すように、このようなサービスユーザインスタンスは、アプリケーション固有のポリシに基づき、現在の活動の状態をロールバックし、解除処理を開始することによってこのようなイベントに応答し、続いて、ミューテックスの解除を強制する。なお、（アプリケーション固有のポリシに基づき、若しくはブロック又は誤った振る舞いのために）このサービスユーザインスタンスの動作が異なる場合でも、他のインスタンスは、ミューテックスの取得の際に、（ｇｅｔメソッドを呼び出す試みに関して、所定回数の失敗の後に）失敗ケースを示すプリミティブであるｂｏｏｋＮｅｇｏｔｉａｔｉｏｎＣｆｍ（又は、再交渉の場合ｂｏｏｋＲｅｎｅｇｏｔｉａｔｉｏｎＣｆｍ）（それぞれ図３１及び図３３参照）に基づいて、延期された遅延を検出できる。このような場合、通知されたＥ２ＥＮＰ  ＵＡサービスユーザインスタンスは、アプリケーション固有のアービトレーションユニットの仲介を呼び出してもよい。これらの全ての例外的なケース／デッドロックを管理するために、必要に応じて、現在の所定のセッションを取り消して、ミューテックスを解除するｒｅｓｅｔＲｅｑプリミティブを発行できる。
【０１９３】
ミューテックスエンティティを用いる場合に発生する主な問題は、所謂優先順位反転問題（priority inversion problem）である。これは、ミューテックスを所有しているタスクＴｊの優先順位が、ミューテックス上でブロックされている他のタスクＴｋの優先順位より低い場合に必ず発生し、より正確には、優先順位がＴｊより高いがＴｋより低いタスクＴｌによって、Ｔｊがプリエンプト（横取り）される場合に必ず発生する。
【０１９４】
Ｅ２ＥＮＰ  ＵＡサービスユーザとＳＩＰ  ＵＡ１１０の両方に疎結合されたインタフェースを強制する設計を選択した場合、「＿ＲｅｓｖＭｔｘ」インプリメンテーションを含むＥ２ＥＮＰ  ＵＡ１２８には、例えば、優先順位継承プロトコル又は優先順位シーリングプロトコル等の周知のプロトコルを直接は適用できない。これは、最終的に、ソフトウェアコンポーネントとしてＥ２ＥＮＰ  ＵＡ１２８を設計した結果である。
【０１９５】
但し、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６が複数のＦＳＭ１０６のインスタンスを同時に処理するスレッドプールを扱うように設計した場合、優先順位反転問題は、少なくともこのレベルにおいては、解決可能となる。これに関連して、優先順位継承プロトコルを適用することにより、上述した問題を処理する性能が向上する。この意味において、各Ｅ２ＥＮＰ  ＵＡサービスユーザインスタンスが発行するｂｏｏｋＮｅｇｏｔｉａｔｉｏｎＲｅｑプリミティブのパラメータリストにおける特定の優先順位（又は再交渉ケースのｂｏｏｋＲｅｎｅｇｏｔｉａｔｉｏｎＲｅｑ、ＴＡＢ１参照）が、そのＦＳＭ１０６インスタンスを提供するスレッドの優先順位として、割り当てられる。したがって、「＿ＲｅｓｖＭｔｘ」は、ブロックされたスレッドの優先順位がミューテックスを所有しているＦＳＭ１０６インスタンスに関連するスレッドの優先順位より高い場合、そのブロックされたスレッドの優先順位に対して、ミューテックスを所有しているＦＳＭ１０６インスタンスに関連するスレッドの優先順位を一時的に高める。
【０１９６】
このように、Ｅ２ＥＮＰ  ＵＡ１２８は、デッドロック及び優先順位反転問題を解決するツールを提供する。但し、これらの問題を完全に解決できるか否かは、このようなツールを用いるアプリケーション１３０又はＱｏＳブローカ１３０次第である。
【０１９７】
以下のサブセクションでは、リソース予約調整処理について説明する。
【０１９８】
ＮｅｇＡｎｓｗｅｒｅｒサブ状態（図３２参照）及びＲｅＮｅｇＡｎｓｗｅｒｅｒサブ状態（図３４参照）は、それぞれ同じ複合状態のインスタンスであるＷａｉｔＦｏｒＣｏｏｒｄＤｏｎｅサブ状態（図３６参照）を含んでいる。ＷａｉｔＦｏｒＣｏｏｒｄＤｏｎｅサブ状態のネスト構造のＦＳＭ１０６は、アンサ側が実際に通知を受け取り、及びオファー側がそれに対応する通知を行う前に、リソース予約シグナリングの調整（coordination）を扱うロジックを捕捉する。
【０１９９】
リソース予約調整処理は、［Ｃａｍ１］に開示されているメカニズムに基づいているが、ここでは、以下の点を改善している。
１．［Ｃａｍ１］に開示されている必須条件をＥ２ＥＮＰ「ｑｏｓｄｅｆ」セクション及び［ＲｅｑＳｐｅｃ］に開示されている対応する交渉処理にマッピングすることができる。
２．Ｅ２ＥＮＰは、「経済原理」のために、強制的に、ピアの間の予約処理の同期を指示する（［Ｃａｍ１］の「確認（confirm）」タグ）これは、「確認」タグのエンドツーエンドシグナリング（又は、これに同等なもの）が不要であり、したがって、如何なるＥ２ＥＮＰインプリメンテーションもこれをサポートする必要がないことを意味する。
３．オファー側によって、ネットワークリソース予約が行われなかった場合、アンサ側は、オファー側から送られた必須条件を調べることによって、この事実を確認し、図３６に示すように、これに応じて、状態ＲｅｍｏｔｅＴｏｋｅｎＡｃｈｉｅｖｅｄをアクティブとしてマークし、これによりアンサ側は、リソース予約調整をトランスペアレントに取り扱うことができる。
【０２００】
ＳＩＰインプリメンテーションに対する影響（例えば、ステータス応答の導入及びＯＰＴＩＯＮＳメソッドの「サポートされた」ヘッダフィールドのための新たな値「必須条件（precondition）」）は、更なる研究課題である。
【０２０１】
重要な点は、［ＲｅｑＳｐｅｃ］に開示されているＥ２ＥＮＰは、エンドツーエンドの予約及びセグメント化された予約の両方を実現するための［Ｃａｍ１］に開示されている概念を含む経済原理が常に必要であることを明示的に主張する点である。後者のケースでは、経済原理を適用することが常に望ましいとは限らない。実際、コスト及び／又はセッション確立への大きな影響なしで、最初から、ローカルの予約が成功する場合がある。例えば、一部のユーザを、ネットワークリソース予約を自由に行うことができ、他のユーザの飢餓状態を柔軟に処理するイントラネット又は無線ＬＡＮに接続してもよい。したがって、元のＥ２ＥＮＰは、この状況に対応し、上述の状況を実現する経済原理の適用可能性に頼っている。
【０２０２】
なお、Ｅ２ＥＮＰは、予約エンティティへのダイレクトインタフェースが利用可能であることを意味するものではない。これらのエンティティにアクセスできるか否かは、アプリケーション１３０又はＱｏＳブローカ１３０次第である。ＱｏＳブローカ１３０がネットワークリソースの「事前予約（pre-reservation）」を希望する場合、ＱｏＳブローカ１３０は、事前予約を行ってもよいが、このような場合でも、Ｅ２ＥＮＰシグナリングは、アプリケーション１３０又はＱｏＳブローカ１３０に正しいタイミングを与え、これにより、全ての側における予約が経済原理に基づいて実現されたとき、例えば、どの信号が必要なＱｏＳのレベルに達したかを知らせる（それぞれアプリケーション１３０又はＱｏＳブローカ１３０によって指定される場合、予めベストエフォート型通信を開始してもよい）
説明を簡潔にするために、図３０〜３６に示すモデルは、予期せぬイベント及びエラーケースの処理については、部分的にしか示していない。ＴＡＢ１８は、このようなイベント又はエラーの発生に応じて、予想された振る舞いを示すことによってこのモデルを完全に記述している。
【０２０３】
Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６がサービスユーザ及び／又はＳＩＰ  ＵＡ１１０からのイベントを待機する状態でスタックすることを回避するために一組のタイマを定義する。Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂ（Ｔ１−Ｔ２２）に亘るプリミティブを制御するタイマの処理は、幾つかの状況（Ｒｏｏｔ．ＮｅｇＯｆｆｅｒｅｒ．ＷａｉｔＮｅｇＲｅｑにおけるｎｅｇｏｔｉａｔｉｏｎＲｅｑ及びＲｏｏｔ．ＲｅＮｅｇＯｆｆｅｒｅｒ．ＷａｉｔＲｅＮｅｇＲｅｑにおけるｒｅｎｅｇｏｔｉａｔｉｏｎＲｅｑが失われた場合）を除いて、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６が自律的な補正動作を行うようには指示しない。Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、誤った振る舞いを示すサービスユーザに対し、ｆａｉｌｕｒｅＩｎｄプリミティブを用いて、検出された問題を単に通知し、これに応じて、サービスユーザは、ｒｅｌｅａｓｅＲｅｑプリミティブを整理（clean up）し、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６に送る。但し、例えば、サービスユーザ側の規模的な問題のためにこの対策が成功しない場合、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、更なる期限の満了の際に、この状況を検出する。この場合、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、ＳＩＰ接続と全体的なＥ２ＥＮＰセッションを終了する最終的な判断を下す。これらの全ての例外的な状況／デッドロックを管理するために、必要に応じて、いつでも、ｒｅｓｅｔＲｅｑプリミティブを発行し現在の所定のセッションを取り消し、ミューテックスを解放することができる。
【０２０４】
但し、複合状態Ｒｏｏｔ．ＲｅＮｅｇＯｆｆｅｒｅｒ、Ｒｏｏｔ．ＮｅｇＡｎｓｗｅｒｅｒ、Ｒｏｏｔ．ＲｅＮｅｇＯｆｆｅｒｅｒ、Ｒｏｏｔ．ＲｅＮｅｇＡｎｓｗｅｒｅｒは、それぞれ履歴状態（図３１、３２、３３、３４参照）を用いて、（最終的に、ｆａｉｌｕｒｅＩｎｄプリミティブの呼出によってトリガされる）失われたプリミティブの後の到着を検出できる。このソリューションにより、遅れて到着したプリミティブは、元の正しい状態で捕捉され、正しく処理される。これは、上述したタイマの期限が満了すると、上述した複合状態は、タイマの期限が満了した状態を示すように、それぞれ履歴を更新することを意味する。
【０２０５】
ＳＩＰプリミティブが失敗した場合、特定のタイマ（Ｔ１０１〜Ｔ１０６）がＲｏｏｔ．ＲｅＮｅｇＯｆｆｅｒｅｒＲｏｏｔ．ＮｅｇＡｎｓｗｅｒｅｒ、Ｒｏｏｔ．ＲｅＮｅｇＯｆｆｅｒｅｒ、Ｒｏｏｔ．ＲｅＮｅｇＡｎｓｗｅｒｅｒ複合状態において、失敗を検出する。これらの場合、（ｆａｉｌｕｒｅＩｎｄプリミティブに基づいて）上述と同様の手続が実行される。
【０２０６】
インタフェースについては、管理エンティティ１０２によって、プリミティブの失敗の潜在的な問題に対処するための手法と同様の手法を適用する。但し、このセクションでは、この処理の詳細については述べない。
【０２０７】
Ｅ２ＥＮＰ概念を適切にインプリメントするために、デュアルシージャイベント（dual seizure event）（ピアが互いに同時に交渉セッションを開始するイベント）が適切に検出及び処理され、これにより、一貫性が保証され及び送受される招待間の全ての相関性が保たれる。
【０２０８】
ミューテックスを用いて、システム全体の単位で経済原理フェーズへのアクセスを規制する（上述のセクションに説明した「＿ＲｅｓｖＭｔｘ」）ことによって、一貫性が保証される。一方、招待間の全ての相関を保つためには、何らかの追加的な対策が必要となる。ここでは、２つの可能な手法について説明する。
ａ．プッシュプル型モデルを用いて、オファー側とアンサ側の両方がオファーを相手側に送る機会を有するようにし、これにより、同じセッションについて、両方向での２つの交渉が同時に生成されることを回避する。
ｂ．両方向の交渉を同時に処理する試みを、競合解決ポリシ（例えば、両側で、ランダムタイマによる期間を待機した後、再試行する）の適用を要求するダブルシージャ（double seizure）として扱う。但し、これは、ダブルシージャを検出可能とするために、両方のピアがセッションＩＤの同じ外部表現を用いなくてはならないことを意味する。外部表現が異なる場合、２つのＵＡは、それぞれ送受する交渉を独立したセッションとして処理する。これは、例えば、ピアＡがピアＢをビデオ会議に招待し、ピアＢがピアＡを他のビデオ会議に招待するような状況と同じであり、ビデオ会議は、実際には、同じであってもよい。［ＲｅｑＳｐｅｃ］に開示されている手法に基づいてＥ２ＥＮＰがセッションＩＤの外部表現を定義することにより、２つのピアが生成するＩＤは、必ず異なるものとなる。このように、Ｅ２ＥＮＰ−仕様自体では、ダブルシージャを検出することはできない。
【０２０９】
この問題への妥当なソリューションは、可能な限り、プッシュプル型モデル（第１の手法）を適用し、再交渉フェーズにおいて、アンサ側が後に（すなわち、第１の交渉が完全に終了した後に）オファーをオファー側に送ることができるようにすることである。
【０２１０】
これは、Ｅ２ＥＮＰにより、オファー側及び／又はアンサ側がＱｏＳアウェアなマルチメディアセッションを確立するための更新された又は新たな情報について、他のアンサ側及び／又はオファー側と交渉できることを意味する。更に、これは、再交渉を以下の２つのクラスに分割できることを意味する。
・［ＲｅｑＳｐｅｃ］に開示されている計画された再交渉（planned re-negotiations）。
・セッションの継続期間の間、更新された又は新たな情報を交渉するために用いられる計画されていない再交渉（unplanned re-negotiations）。
【０２１１】
前交渉プリミティブにおいて明示されるブールパラメータは、所定のプリミティブが２つのクラスの何れに用いられるかを示す。勿論受け取った情報からセマンティクスを推論することもできる。この情報は、２つの状況でそれぞれ異なる場合もある。なお、ブールパラメータは、このような相異がある場合、好ましいトレードオフである。これは、性能を向上させ、更なるプリミティブの追加を回避することによってＥ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂ及びＦＳＭ１０６の構造を単純にするために明示的に作成されている。
【０２１２】
但し、Ｅ２ＥＮＰに準拠しないＳＩＰ  ＵＡ１１０がＥ２ＥＮＰに準拠するピアに干渉する可能性があり、又は、参加するピアの１つが他の幾つかのピアを並列マルチメディアセッションに招待しようと試み、これを達成するためにＥ２ＥＮＰを用いることがあるため、上述のソリューションは、一般的な状況では、不十分であることがある。
【０２１３】
ＳＩＰでは、競合解決ポリシ（［Ｒｏｓ１］では、「ＭＡＹ」要求と呼ばれる）を提案することによってデュアルシージャ問題の解決を試みる。ここでは、ピアは、リモートピアが再試行する期間の経過後に、Ｒｅｔｒｙ−ＡｆｔｅｒＳＩＰヘッダフィールドを含む内部サーバエラー応答を返すことによって招待を中止する。
【０２１４】
デュアルシージャの検出は、Ｔｏ−ＳＩＰヘッダフィールド及びＦｒｏｍ−ＳＩＰヘッダフィールドについて、所定のユーザの対の間の全てのメッセージを照合することによって実行される。これは、例えば、ＵＡ  Ａ上の第１のユーザがＵＡ  Ｂ上の第２のユーザにＩＮＶＩＴＥを送る場合、又はこの逆の場合、何れのユーザも、（Ｔｏ，Ｆｒｏｍ）の対を２つのＩＮＶＩＴＥを関連付けるための一意的な識別子として用いることによって、デュアルシージャを検出できることを意味する。
【０２１５】
但し、これは、Ｅ２ＥＮＰがセッションを特定する手法と正確には一致しない。ユーザが２つの異なるビデオ会議に登録している場合、Ｅ２ＥＮＰは、［ＲｅｑＳｐｅｃ］に開示されているセッションＩＤを用いることによって実際にこのような状況を識別できる。何れの場合も、最も大きな問題は、ＳＩＰ要求がＭＡＹ要求であり、したがって、全てのＳＩＰインプリメンテーションがサポートしているとは限らない場合に、このような状況において、ＳＩＰ  ＵＡ１１０が何をするかである。
【０２１６】
ここで、上述のポリシがインプリメントできる可能性を仮定する必要がある。すなわち、Ｅ２ＥＮＰ  ＵＡ１２８は、交渉フェーズ又は再交渉フェーズの失敗を示す情報がなければ、デュアルシージャを検出できない。また、基本的なＳＩＰ  ＵＡ１１０インプリメンテーションによっては競合解決ポリシがサポートされない場合、デュアルシージャに関する問題が生じる可能性がある。
【０２１７】
この問題に対処するするために、キャッシュ１０４は、各エントリについて、送信されるＩＮＶＩＴＥに関連する（Ｅ２ＥＮＰＦｒｏｍＡｄｄｒｅｓｓ、Ｅ２ＥＮＰＴｏＡｄｄｒｅｓｓ）の対を保存し、この情報を用いて受信されるＩＮＶＩＴＥをキャッシュ１０４に登録されている保留中の送信された招待に関連付け、これにより、デュアルシージャの状況を検出する必要がある。これにより、競合解決ポリシがトリガされる。これは、ＩＮＶＩＴＥを送信した後に受信される全てのＩＮＶＩＴＥを、（Ｆｒｏｍ、Ｔｏ）の対を用いて、セカンダリキーにより、キャッシュ１０４を検索することによって検査する必要があることを意味する。これは、追加的な負荷を強いる処理であるが、このような処理を行う必要性は、ＩＮＶＩＴＥを送信した後にＩＮＶＩＴＥを受け取るという、特別な状況のみにしか発生しない。
【０２１８】
［Ｒｏｓ１］によって開示されている、基本的なＳＩＰ  ＵＡ１１０によってインプリメントされる競合解決ポリシに代わる手法として、Ｅ２ＥＮＰ  ＵＡ１２８は、［ＲｅｑＳｐｅｃ］に開示されている一対多又は多対多の場合のようなより複雑なシナリオに適用できる、より一般的なポリシをサポートする。
【０２１９】
交渉又は前交渉フェーズを開始する場合、Ｅ２ＥＮＰ  ＵＡ１２８は、送信されるオファーにおいて、ＩＮＶＩＴＥ内に［ＲｅｑＳｐｅｃ］に開示されているセッションＩＤのみではなく、そのハッシュも含ませる必要がある。このハッシュは、Ｅ２ＥＮＰ  ＵＡ１２８がアカウントとタイムスタンプに有効である演算装置のＩＰアドレスを示す。また、［ＲｅｑＳｐｅｃ］の機密保護性能を向上させるために、このハッシュは、デジタル署名であってもよい。ハッシュは、後のＳＩＰメッセージにおいて、セッションＩＤの代替として用いることもできる。デュアルシージャが発生すると、Ｅ２ＥＮＰは、上述した（Ｆｒｏｍ、Ｔｏ）の対を用いて、これを検出する。このため、上述した競合解決ポリシは、以下のように適用される。
・２つのピアが未だマルチメディアセッションに含まれていない場合（所定のローカルピアのエントリがキャッシュ１０４に登録されていないことを意味する）、各ピアは、自らが生成したハッシュを、他のピアから受け取ったハッシュと比較する。最大値を有するピアは、オファー側として自動的に選択され、前交渉又は交渉フェーズを継続し、他方のピア、すなわち「敗者（loser）」は、以下のＭＳＣに基づいて、アンサ側モードに自動的にアンサ側モードに移行する。
【０２２０】
【表３】
2006504363.tif 000006
【０２２１】
・２つのピアが既にマルチメディアセッションに含まれている場合（所定の（Ｆｒｏｍ、Ｔｏ）対のエントリがキャッシュ１０４に登録されていることを意味する）、上述した「ブリー（bully）」処理を適用することができる。要求を拒絶されたピアは、「ブリー」処理の勝者が交渉を終了した後に、計画されていない再交渉を実行してもよい。このような場合の具体例としては、同時検出及びセッションに関わるピアによるＱｏＳ違反に対する再交渉応答がある。
・また、セッションＩＤは、識別のために、（ＩＰ、ポート等の情報とともに）ランダムに生成された数値を含んでいるので、何れかのピアが常に「勝者」となったり、常に「敗者」となったりすることは期待できない。
【０２２２】
更に、上述の競合解決処理は、前交渉手続と衝突する交渉手続の場合にも適用され、又は、リース更新された手続（lease-renewed procedure）及び前交渉手続とリース更新された手続の衝突の場合にも適用される。
【０２２３】
先のサブセクションに開示されているモデルは、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の静的な定義を表す。実行時には、Ｅ２ＥＮＰ  ＵＡ１２８は、特定のＥ２ＥＮＰセッションを、このセッションを表すオブジェクトに関連付ける。このオブジェクト（セッション）は、所定のＥ２ＥＮＰインスタンスに関連するあらゆる情報、特に、現在の状況へのポインタ及び上述のモデルにおいて定義されている全ての条件変数のインスタンスを含むものとする。
【０２２４】
実行のスレッドは、要求に応じて作成され、又は、好ましくは、スレッドプールから取り出される（潜在的に効率的な初期化）これらのセッションオブジェクトのそれぞれに動的に関連付けられる。
・Ｅ２ＥＮＰのこのバージョンは、［Ｒｏｓ１］に開示されているＳＩＰプロトコル仕様に基づいている。後に、他のセッションレベルプロトコル又はより包括的な手法が選択された場合、ＦＳＭ１０６は、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂ抽象化のために、アプリケーション１３０又はＱｏＳブローカ１３０から対応する変化をマスキングするよう修正する必要がある。これは、ＦＳＭ１０６とＥ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂサービスユーザとのインタラクションは、設計に依存しないことを意味する。
・ＳＩＰ  ＭＥＳＳＡＧＥメソッドの使用例を図３０に例示的に示す。これに代えて、ＳＩＰ  ＯＰＴＩＯＮＳメソッドを用いてもよい。本発明の範囲では、後述するＦＳＭ１０６モデルをインプリメントする前者の用法は、未だ検討中であるため、ＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃによって、後者だけが提供される。
・Ｅ２ＥＮＰ  ＵＡ１２８が安定状態構成に達する前に、Ｅ２ＥＮＰ  ＵＡ１２８へのインタフェースを司るエンティティ（例えば、Ｅ２ＥＮＰ  ＵＡ１２８サービスユーザ、ＳＩＰ  ＵＡ１１０及びＥ２ＥＮＰ管理エンティティ１０２）がＥ２ＥＮＰ  ＵＡ１２８から出るプリミティブに対応して、Ｅ２ＥＮＰ  ＵＡ１２８に入るプリミティブを直接呼び出すことを回避するために、Ｅ２ＥＮＰ  ＵＡ１２８は、設計上、常に、外部のエンティティに疎結合されている。このような設計を選択する他の理由としては、このような設計を行わなければ、Ｅ２ＥＮＰ  ＵＡ１２８へのインタフェースを司るエンティティがＥ２ＥＮＰ  ＵＡスレッドを無期限にブロックしてしまう非ヌル確率（non-null probability）が生じる可能性があるためである。
・これは、Ｅ２ＥＮＰ  ＵＡ１２８が、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６全体に対して、１つの受信メッセージキューを適用するとともに、インタフェースＩＦ１、ＩＦ２及びＩＦ３のそれぞれに対して、送信メッセージキューを適用することを意味する。送信メッセージキューを適用する理由は、ソフトウェアコンポーネントであるＥ２ＥＮＰ  ＵＡ１２８では、アプリケーション１３０がＵＡからのプリミティブを処理する手法に関する仮定を設けることができないという事実のためである。
・パーサ１１２及びファクトリ１１４は、同期インタフェースを介してＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６によってアクセスされるスレッドセーフで、再入可能なライブラリとして設計されるのでこの手法は、ＩＦ４及びＩＦ５には不要である。
・Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の同時に発生するインスタンスはスレッドプールを用いて処理される。
【０２２５】
Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、以下のコンポーネントに依存する。
・ＦＳＭ１０６によってインプリメントされるＥ２ＥＮＰ機能を提供するＥ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂ
・受信したＳＩＰメッセージに含まれるセッション記述を解析するアクセスサービスのために用いられるパーサＡＰＩ１０１ｄ
・送信されるＳＩＰメッセージに挿入されるセッション記述を作成するアクセスサービスのために用いられるファクトリＡＰＩ１０１ｅ
・ＳＩＰサービスへのアクセスのために用いられるＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃ
・総合的なＥ２ＥＮＰ  ＵＡ１２８管理機能を担うアクセスサービスのために用いられるＥ２ＥＮＰ管理ＡＰＩ１０１ａ
・所定のセッションの識別子を保存し、相関させるために用いられるキャッシュ１０４
図３０、図３１、図３２、図３４及び図３６は、ＵＭＬ状態図を用いてＥ２ＥＮＰ  ＵＡ  ＦＳＭモデルを示しており、このモデルは、様々な周知の設計パターンを用いてインプリメントできる。何れの場合も、図１に示すように、実行時には、ＦＳＭ１０６は、適用されたフレームワークのインスタンスに又はモデルをインプリメントする設計パターンに関連付けられている。各インスタンスは、特定のＳＩＰフェーズ［ＲｅｑＳｐｅｃ］すなわち、前交渉、リース更新又は交渉に関連している。再交渉は、対応する交渉に関して確立される基底にあるセッションと同じインスタンス上で実行される。
【０２２６】
ＦＳＭ１０６インスタンスのライフサイクル（作成、アクティブ化、非アクティブ化、終了）を扱うために、ＦＳＭインスタンスファクトリ１０６（図１参照）を用いる。これは、特定のＥ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂプリミティブの呼出（ｎｅｇｏｔｉａｔｉｏｎＲｅｑ、ｐｒｅｎｅｇｏｔｉａｔｉｏｎＲｅｑ、ｒｅｎｅｗＬｅａｓｅＲｅｑ）又は特定のＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃプリミティブの呼出（ｃｏｎｎｅｃｔｉｏｎＩｎｄ、ｏｐｔｉｏｎｓＩｎｄ、ｍｅｓｓａｇｅＩｎｄ）に応じてＦＳＭ１０６のインスタンスを作成する単集合オブジェクトである。
【０２２７】
図３７は、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６を介した、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂとＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの間の相関を強調した、簡単な前交渉シナリオのＭＳＣを示している。
【０２２８】
図３８は、Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６を介した、Ｅ２ＥＮＰ  ＵＡ  ＡＰＩ１０１ｂとＳＩＰ  ＵＡジェネリックＡＰＩ１０１ｃの間の相関を強調した、簡単なセッション確立シナリオのＭＳＣを示している。このシナリオでは、オファー側からのリソース予約完了の確認は、同様の確認がアンサ側で行われる前に到着する。同様に、リソース予約処理では、本来要求された量のリソースの予約が成功することが仮定される。
【０２２９】
以下のサブセクションでは、Ｅ２ＥＮＰ  ＵＡファクトリ１０８について簡潔に説明する。
【０２３０】
Ｅ２ＥＮＰ  ＵＡファクトリ１０８は、インプリメンテーション独立のインタフェースを用いて、特定のＥ２ＥＮＰ  ＵＡ１２８インプリメンテーションをインスタンス化するために、［Ｇａｍ］に開示されている「抽象的なファクトリ」設計パターンに基づいてモデル化された管理機能である。
【０２３１】
このエンティティは、Ｅ２ＥＮＰ  ＵＡ１２８のインスタンスを作成するために必要な上述したセクションに示した全てのクラスのインスタンス化を担う。詳しくは、Ｅ２ＥＮＰ  ＵＡファクトリ１０８は、以下のエンティティを作成する。
・Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ静的構造（static structure）を生成するＥ２ＥＮＰ  ＵＡ  ＦＳＭファクトリ
・Ｅ２ＥＮＰファクトリ１１４を生成するＦａｃｔｏｒｙＦａｃｔｏｒｙ１２０
・Ｅ２ＥＮＰパーサ１１２を作成するＰａｒｓｅｒＦａｃｔｏｒｙ１１８
・キャッシュ１０４
このため、Ｅ２ＥＮＰ  ＵＡファクトリ１０８は、以下のコンポーネントに依存する。
・Ｅ２ＥＮＰ  ＵＡファクトリ１０８又は管理エンティティ１０２を直接呼び出すことができるアプリケーション１３０及び／又はミドルウェア１３０
・所定の具体的なＥ２ＥＮＰ  ＵＡファクトリインプリメンテーションによってファクトリが生成されるＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６
・所定の具体的なＥ２ＥＮＰ  ＵＡファクトリインプリメンテーションによってファクトリが生成されるファクトリ１１４とパーサ１１２
・所定の具体的なＥ２ＥＮＰ  ＵＡファクトリインプリメンテーションによって生成されるキャッシュ１０４
Ｅ２ＥＮＰ  ＵＡファクトリ１０８は、オブジェクト指向パラダイムを用いて設計されている。したがって、ここでは、Ｅ２ＥＮＰ  ＵＡファクトリ１０８を統一モデリング言語（ＵＭＬ）を用いて記述する。
【０２３２】
以下では、Ｅ２ＥＮＰオブジェクト構造パラメータを簡潔に要約する。
【０２３３】
Ｅ２ＥＮＰ  ＵＡ１２８とそのサブコンポーネント（ＦＳＭ１０６、パーサ１１２、ファクトリ１１４、キャッシュ１０４）は、構成可能なエレメントである。初期構成では、Ｅ２ＥＮＰ  ＵＡ１２８を用いるピアの特定の特徴を考慮するべきである。
【０２３４】
Ｅ２ＥＮＰ  ＵＡ１２８は、以下のパラメータで初期化される。
・Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６は、性能に関する速やかな決定を下す必要がある重要な状態に関する特定の期限が経過したときに開始される。この期間の長さはＥ２ＥＮＰ  ＵＡ１２８の基底にある特定のプロトコル及び各ピアの性能特性に基づいて定められる。デバイス及びネットワークが異なれば、この期限は、ある程度変化することがある。設計者は、期限を定義するにあたり、これらの変化を考慮する必要がある。
・キャッシュ１０４は、如何なる構造パラメータも必要とせず、Ｅ２ＥＮＰ  ＵＡ１２８によって開始される。
・パーサ１１２とファクトリ１１４は、使用されている基底のプロトコル種類と、それらの各クラス名とによってそれぞれ構成される。パーサ１１２とファクトリ１１４は、Ｅ２ＥＮＰ  ＵＡ１２８によって開始される。
【０２３５】
Ｅ２ＥＮＰ  ＵＡ１２８及びその各コンポーネントの構成は、グラフィカルユーザインタフェース（ＧＵＩ）を用いて手動で、又は設定ファイルから読み出される構成パラメータによってプリセットすることにより実行できる。
【０２３６】
Ｅ２ＥＮＰ  ＵＡ  ＦＳＭ１０６に関しては、以下のパラメータが構成可能である。
・スレッドプール構造パラメータ：
・Ｅ２ＥＮＰスレッドプールのスレッドの最大数
・プールが遅延初期化を有するか否かを示すセレクタ（すなわち、スレッドは、必要な場合のみ作成される）
・スレッドプール最適化が必要であるか否かを示すセレクタ（遅延初期が適用される場合のみ）最適化のために、プールは、実際のプールの用途に基づいて、実行時において再構成してもよい。
【０２３７】
−スレッドプール最適化期限：このような期限が経過すると、最適化処理が適用される（すなわち、未使用のスレッドが解放される）
・タイマ（ＴＡＢ１９参照）
・ミューテックス：
・最終的にＦＳＭ１０６の優先順位が低いインスタンスに基づくミューテックスの潜在的な無期限のロックを検出するための期限（ＴＡＢ１９のＴＭ参照）
・ミューテックスを得る試みを実行する回数は、所定の最大数によって制限される（最大の試み：Max-Attempts）
ＳＩＰ  ＵＡインプリメンテーション１１０により、少なくとも以下のパラメータを構成することができる。
・基底にあるセッションプロトコル。これは、メタメッセージ（ＳＩＰ、ＲＭＩ、ソケット）を搬送するためにＥ２ＥＮＰによって用いられるプロトコルである。Ｅ２ＥＮＰの将来の仕様では、他のセッションレイヤプロトコル（例えば、Ｈ３２３）を用いることもできる。
・基底にあるトランスポートプロトコル：これは、ＳＩＰによって用いられるトランスポートプロトコルの種類を示す。将来の仕様では、このパラメータは、ＳＩＰ  ＵＡ１１０自体に関する構造パラメータとなる可能性もある。
【０２３８】
以下のサブセクションでは、それぞれファクトリ１１４と同期させてＥ２ＥＮＰ  ＵＡ１２８とパーサ１１２の間で通信を実現するための判定に関する情報を開示する。これに関連して、Ｅ２ＥＮＰ  ＵＡ１２８は、同時に発生するＥ２ＥＮＰ  ＵＡ  ＦＳＭ１０６の複数のインスタンスをサポートするものとする。ＯＳリソースが無制限に使用されることを回避するために、Ｅ２ＥＮＰ  ＵＡ１２８は、スレッドプールを適用する。
【０２３９】
Ｅ２ＥＮＰ  ＵＡ１２８とパーサ１１２の間の通信は、例えば、能動要求インタフェース及び受動確認インタフェースによってインプリメントされ、それぞれファクトリ１１４と非同期であってもよい。このオプションは、Ｅ２ＥＮＰ  ＵＡ１２８のＦＳＭ１０６のより複雑な状態モデルによって、性能と柔軟性における利点が犠牲になるので、基本的な本発明の範囲では用いない。
【０２４０】
この選択の結果、Ｅ２ＥＮＰ  ＵＡ１２８及びパーサ１１２（並びにファクトリ１１４も）同期して通信し、これにより、共通アドレス空間を共有する。これは、ほとんどの状況で妥当な仮定である。また、この選択の結果、ＰａｒｓｅｒＦａｃｔｏｒｙ及びＦａｃｔｏｒｙＦａｃｔｏｒｙは、何れも、スレッドセーフで再入可能なライブラリとして設計する必要がある。
【０２４１】
上述の説明から、Ｅ２ＥＮＰ  ＵＡ１２８及びパーサ１１２並びにファクトリ１１４の間の通信は、同期される。
【０２４２】
結論として、従来の技術に対する本発明の利点を説明する。簡潔に言えば、ここで提案する手法の主な利益は、以下のようになる。
・ＱｏＳ前交渉において、前交渉された情報、ＱｏＳ交渉及びＱｏＳ再交渉のリースベースの管理を実現できる。
・Ｅ２ＥＮＰ  ＵＡ１２８によって、リソース予約及び／又は解除が調整される。
【０２４３】
更に、交渉すべき情報（能力、アプリケーションレベルＱｏＳ契約、ネットワークレベルＱｏＳ契約、ストリームレベル適応化パス、ストリームグループレベル適応化パス）は、交換可能なフォーマットで表現される。この表現は、異種のアプリケーション１３０及び／又はミドルウェア１３０が参照モデルに容易に同意でき、アプリケーション１３０及び／又は上記ミドルウェア１３０がこの参照モデルを用いて、有限状態マシン（ＦＳＭ）１０６を動的に構成するように実現される。これにより、各ユーザの嗜好及びプロファイル、及び各システム及びネットワークプロバイダのポリシに基づいて、様々なピアが用いる複数の異種のアプリケーション１３０とミドルウェア１３０の間で調整された手法で、ローカルリソース、ピアのリソース及びネットワークリソースを調整することができる。
【０２４４】
Ｅ２ＥＮＰ  ＵＡ１２８は、セッションレイヤプロトコル及びセッション記述言語を問わず使用でき、複数のアプリケーション１３０に対応し、異なる種類のミドルウェア１３０にも用いることができる。
【０２４５】
【表４】
2006504363.tif 000007
【０２４６】
【表５Ａ】
2006504363.tif 000008
【０２４７】
【表５Ｂ】
2006504363.tif 000009
【０２４８】
【表５Ｃ】
2006504363.tif 000010
【０２４９】
【表５Ｄ】
2006504363.tif 000011
【０２５０】
【表５Ｅ】
2006504363.tif 000012
【０２５１】
【表５Ｆ】
2006504363.tif 000013
【０２５２】
【表５Ｇ】
2006504363.tif 000014
【０２５３】
【表５Ｈ】
2006504363.tif 000015
【０２５４】
【表５Ｉ】
2006504363.tif 000016
【０２５５】
【表５Ｊ】
2006504363.tif 000017
【０２５６】
【表５Ｋ】
2006504363.tif 000018
【０２５７】
【表５Ｌ】
2006504363.tif 000019
【図面の簡単な説明】
【０２５８】
【図１】本発明に基づき、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたアーキテクチャを示すブロック図である。
【図２】ＪａｖａベースのＳＩＰスタック（ＪＳＩＰ）及びＳＤＰｎｇパーサとファクトリを用いる本発明の一実施形態に基づく、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）のための適用されたアーキテクチャの第１のインプリメント例を示す図である。
【図３】ＳｕｎのＪａｖａリモートメソッド呼出（ＲＭＩ）を用いる本発明の一実施形態に基づく、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）のための適用されたアーキテクチャの第２のインプリメント例を示す図である。
【図４】ソケットベースのユーザデータグラムプロトコル（ＵＤＰ）又は伝送制御プロトコル（ＴＣＰ）を用いる本発明の一実施形態に基づく、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）のための適用されたアーキテクチャの第３のインプリメント例を示す図である。
【図５Ａ】ｏｒｇ：：ｍｉｎｄ：：ｅ２ｅｎｐパッケージを示すＵＭＬクラス図である。
【図５Ｂ】Ｅ２ＥＮＰ  ＵＡファクトリと管理エンティティの間のＥ２ＥＮＰ管理ＡＰＩを示す図である。
【図６】強化されたＢＮ記法（ＡＢＮＦ）を用いた、Ｅ２ＥＮＰのユニバーサルリソース識別子（ＵＲＩ）の統語構造の具体例を示す図である。
【図７】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）１２８によってイネーブルにされる前交渉手続を示す第１のメッセージシーケンス図（ＭＳＣ）である。
【図８】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）によってイネーブルにされたＱｏＳ交渉及びリソース予約調整によるセッション確立を示す第２のメッセージシーケンス図（ＭＳＣ）である。
【図９】ｏｒｇ：：ｍｉｎｄ：：ｅ２ｅｎｐ：：Ｃａｃｈｅサブパッケージを示すＵＭＬクラス図である。
【図１０】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のために用いられる拡張可能マークアップ言語（ＸＭＬ）記述の上位レベルを示す図である。
【図１１】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のために用いられるＸＭＬ代理グループを示す図である。
【図１２】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のために用いられるＸＭＬ  ｐｕｒｐｏｓｅエレメントを示す図である。
【図１３】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のために用いられるＸＭＬ  ｑｏｓｄｅｆエレメントを示す図である。
【図１４】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のために用いられるＸＭＬ  ｑｏｓｃｆｇエレメントを示す図である。
【図１５】本発明に基づくＥ２ＥＮＰユーザエージェント（ＵＡ）と、適用されたパーサ及びキャッシュとの間のインタラクションを示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図１７】ドキュメントオブジェクトモデル（ＤＯＭ）ツリーの包括的構造を示すＵＭＬクラス図である。
【図１８】ビジター設計パターンを用いてパーサインプリメンテーションの構造的な概要を示すＵＭＬクラス図である。
【図１９】本発明に基づくＥ２ＥＮＰユーザエージェント（Ｅ２ＥＮＰ  ＵＡ）と適用されたファクトリとキャッシュとの間のインタラクションを示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図２０】ファクトリインプリメンテーションの構造的な概要を示すＵＭＬクラス図である。
【図２１】ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉパッケージを示すＵＭＬクラス図である。
【図２２】ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｕｓｅｒＡｇｅｎｔパッケージを示すＵＭＬクラス図である。
【図２３】ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｒｅｇｉｓｔｒａｒパッケージを示すＵＭＬクラス図である。
【図２４】ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｍａｎａｇｅｍｅｎｔパッケージを示すＵＭＬクラス図である。
【図２５】ｏｒｇ：：ｍｉｎｄ：：ｓｉｐ：：ｓｉｐＡｐｉ：：ｔｉｍｅパッケージを示すＵＭＬクラス図である。
【図２６】サービスプロバイダの構成及びサービスユーザとサービスプロバイダのバインディングを示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図２７Ａ】クライアントとサーバのユーザエージェント間の接続確立を示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図２７Ｂ】クライアントとサーバのユーザエージェント間の接続確立を示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図２８】エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のために用いられるＯＰＴＩＯＮＳメソッドを示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図２９】クライアントとサーバのユーザエージェント間の接続解除を示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図３０】ルート状態で実行されるミューテックスに関連する手続を示すネスト構造の有限状態マシン（ＦＳＭ）の第１の状態遷移図である。
【図３１】ＮｅｇＯｆｆｅｒｅｒサブ状態で実行されるミューテックスに関連する手続を示すネスト構造の有限状態マシン（ＦＳＭ）の第２の状態遷移図である。
【図３２】ＮｅｇＡｎｓｗｅｒｅｒサブ状態で実行されるミューテックスに関連する手続を示すネスト構造の有限状態マシン（ＦＳＭ）の第３の状態遷移図である。
【図３３】ＲｅＮｅｇＯｆｆｅｒｅｒサブ状態で実行されるミューテックスに関連する手続を示すネスト構造の有限状態マシン（ＦＳＭ）の第４の状態遷移図である。
【図３４】ＲｅＮｅｇＡｎｓｗｅｒｅｒサブ状態で実行されるミューテックスに関連する手続を示すネスト構造の有限状態マシン（ＦＳＭ）の第５の状態遷移図である。
【図３５】複数の要求が、それらの優先順位に基づいて、連携してミューテックスを獲得できる＿ＲｅｓｖＭｔｘ有限状態マシン（ＦＳＭ）の第６の状態遷移図である。
【図３６】ＷａｉｔＦｏｒＣｏｏｒｄＤｏｎｅサブ状態で実行されるミューテックスに関連する手続を示すネスト構造の有限状態マシン（ＦＳＭ）の第７の状態遷移図である。
【図３７】Ｅ２ＥＮＰユーザエージェント（ＵＡ）のアプリケーションプログラミングインタフェース（ＡＰＩ）及びＳＩＰユーザエージェント（ＵＡ）のジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）の相関に必要であり、したがって、Ｅ２ＥＮＰユーザエージェント（ＵＡ）の有限状態マシン（ＦＳＭ）を用いる前交渉手続を示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図３８Ａ】Ｅ２ＥＮＰユーザエージェント（ＵＡ）のアプリケーションプログラミングインタフェース（ＡＰＩ）及びＳＩＰユーザエージェント（ＵＡ）のジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）の相関に必要であるＱｏＳ交渉手続とリソース予約調整を含むセッション確立を示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図３８Ｂ】Ｅ２ＥＮＰユーザエージェント（ＵＡ）のアプリケーションプログラミングインタフェース（ＡＰＩ）及びＳＩＰユーザエージェント（ＵＡ）のジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）の相関に必要であるＱｏＳ交渉手続とリソース予約調整を含むセッション確立を示すＵＭＬメッセージシーケンス図（ＭＳＣ）である。
【図３９】ＴＡＢ１：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスプロバイダによってインプリメントされたプリミティブのリストを示す図である。
【図４０Ａ】ＴＡＢ２：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスユーザによってインプリメントされるプリミティブのリストを示す図である。
【図４０Ｂ】ＴＡＢ２：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスユーザによってインプリメントされるプリミティブのリストを示す図である。
【図４１】ＴＡＢ３：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、オファー側として機能するサービスユーザによってインプリメントされるプリミティブのリストを示す図である。
【図４２】ＴＡＢ４：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、アンサ側として機能するサービスユーザによってインプリメントされるプリミティブのリストを示す図である。
【図４３】ＴＡＢ５：第１のキャッシュレベルのアプリケーションプログラミングインタフェース（ＡＰＩ）によって提供されるメソッドを示す図である。
【図４４】ＴＡＢ６：第２のキャッシュレベルのアプリケーションプログラミングインタフェース（ＡＰＩ）によって提供されるメソッドを示す図である。
【図４５Ａ】ＴＡＢ７：パーサのアプリケーションプログラミングインタフェース（ＡＰＩ）によってインプリメントする必要があるプリミティブのリストを示す図である。
【図４５Ｂ】ＴＡＢ７：パーサのアプリケーションプログラミングインタフェース（ＡＰＩ）によってインプリメントする必要があるプリミティブのリストを示す図である。
【図４６】ＴＡＢ８：特定のパーサインスタンスを生成するためにインプリメントする必要があるプリミティブのリストを示す図である。
【図４７】ＴＡＢ９：ファクトリのアプリケーションプログラミングインタフェース（ＡＰＩ）によってインプリメントする必要があるプリミティブのリストを示す図である。
【図４８】ＴＡＢ１０：特定のファクトリインスタンスを生成するためにインプリメントする必要があるプリミティブのリストを示す図である。
【図４９】ＴＡＢ１１：周知のｆａｃｔｏｒｙ−ｆａｃｔｏｒｙクラスＥ２ＥＮＰＣｏｎｔｅｎｔＨａｎｄｌｅｒＦａｃｔｏｒｙによって提供されるメソッドを示す図である。
【図５０】ＴＡＢ１２：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスプロバイダによってインプリメントされるプリミティブのリストを示す図である。
【図５１】ＴＡＢ１３：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスユーザによってインプリメントされるクライアント側固有のプリミティブのリストを示す図である。
【図５２】ＴＡＢ１４：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスユーザによってインプリメントされるサーバ側固有プリミティブのリストを示す図である。
【図５３】ＴＡＢ１５：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスユーザによってインプリメントされるクライアント側とサーバ側固有プリミティブの両方のリストを示す図である。
【図５４】ＴＡＢ１６：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスプロバイダによってインプリメントされるプリミティブのリストを示す図である。
【図５５】ＴＡＢ１７：エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のユーザエージェント（ＵＡ）に適用されたジェネリックアプリケーションプログラミングインタフェース（ＡＰＩ）のＪａｖａインプリメンテーションに基づいて、サービスユーザによってインプリメントされるプリミティブのリストを示す図である。
【図５６Ａ】ＴＡＢ１８：適用された例外イベントの概略を示す状態遷移を示す表である。
【図５６Ｂ】ＴＡＢ１８：適用された例外イベントの概略を示す状態遷移を示す表である。
【図５６Ｃ】ＴＡＢ１８：適用された例外イベントの概略を示す状態遷移を示す表である。
【図５６Ｄ】ＴＡＢ１８：適用された例外イベントの概略を示す状態遷移を示す表である。
【図５７Ａ】ＴＡＢ１９：本発明に基づくエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）に適用されるタイマを示す表である。
【図５７Ｂ】ＴＡＢ１９：本発明に基づくエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）に適用されるタイマを示す表である。
【図１】
2006504363.tif 000020
【図２】
2006504363.tif 000021
【図３】
2006504363.tif 000022
【図４】
2006504363.tif 000023
【図５Ａ】
2006504363.tif 000024
【図５Ｂ】
2006504363.tif 000025
【図６】
2006504363.tif 000026
【図７】
2006504363.tif 000027
【図８】
2006504363.tif 000028
【図９】
2006504363.tif 000029
【図１０】
2006504363.tif 000030
【図１１】
2006504363.tif 000031
【図１２】
2006504363.tif 000032
【図１３】
2006504363.tif 000033
【図１４】
2006504363.tif 000034
【図１５】
2006504363.tif 000035
【図１７】
2006504363.tif 000036
【図１８】
2006504363.tif 000037
【図１９】
2006504363.tif 000038
【図２０】
2006504363.tif 000039
【図２１】
2006504363.tif 000040
【図２２】
2006504363.tif 000041
【図２３】
2006504363.tif 000042
【図２４】
2006504363.tif 000043
【図２５】
2006504363.tif 000044
【図２６】
2006504363.tif 000045
【図２７Ａ】
2006504363.tif 000046
【図２７Ｂ】
2006504363.tif 000047
【図２８】
2006504363.tif 000048
【図２９】
2006504363.tif 000049
【図３０】
2006504363.tif 000050
【図３１】
2006504363.tif 000051
【図３２】
2006504363.tif 000052
【図３３】
2006504363.tif 000053
【図３４】
2006504363.tif 000054
【図３５】
2006504363.tif 000055
【図３６】
2006504363.tif 000056
【図３７】
2006504363.tif 000057
【図３８Ａ】
2006504363.tif 000058
【図３８Ｂ】
2006504363.tif 000059
【図３９】
2006504363.tif 000060
【図４０Ａ】
2006504363.tif 000061
【図４０Ｂ】
2006504363.tif 000062
【図４１】
2006504363.tif 000063
【図４２】
2006504363.tif 000064
【図４３】
2006504363.tif 000065
【図４４】
2006504363.tif 000066
【図４５Ａ】
2006504363.tif 000067
【図４５Ｂ】
2006504363.tif 000068
【図４６】
2006504363.tif 000069
【図４７】
2006504363.tif 000070
【図４８】
2006504363.tif 000071
【図４９】
2006504363.tif 000072
【図５０】
2006504363.tif 000073
【図５１】
2006504363.tif 000074
【図５２】
2006504363.tif 000075
【図５３】
2006504363.tif 000076
【図５４】
2006504363.tif 000077
【図５５】
2006504363.tif 000078
【図５６Ａ】
2006504363.tif 000079
【図５６Ｂ】
2006504363.tif 000080
【図５６Ｃ】
2006504363.tif 000081
【図５６Ｄ】
2006504363.tif 000082
【図５７Ａ】
2006504363.tif 000083
【図５７Ｂ】
2006504363.tif 000084
【国際調査報告】
2006504363.tif 000085
2006504363.tif 000086
2006504363.tif 000087
2006504363.tif 000088
2006504363.tif 000089