(57)【要約】  第１のネットワークエンドポイントと第２のネットワークエンドポイントの間の通信のためにネットワークアセットを割り当てる方法は、ネットワークアセットのセットを通して該ネットワークエンドポイント間で呼の流れを開始するためのセッション初期化ｉｎｖｉｔｅをＳＩＰプロキシサーバに提供することを含む。該呼の流れは、アプリケーションサーバ上に常駐するアプリケーションを利用する。該方法は、セッション初期化ｉｎｖｉｔｅの結果としてＳＩＰプロキシサーバからＳＩＰプロトコルマネージャに資源予約メッセージを提供することも含む。資源予約メッセージはウェブサービスインタフェースを介して提供される。該方法は、さらに、該ネットワークエンドポイントを接続する呼の流れ経路を作成するためにネットワークアセットを割り当てるために該ＳＩＰプロトコルマネージャを使用することも含む。該ＳＩＰプロトコルマネージャは、割り当てられるべき必要とされるネットワーク資源の推定値を求めるために該セッション初期化ｉｎｖｉｔｅから情報を抽出する。  【選択図】  図２
2008541301.tif 000002
【特許請求の範囲】
【請求項１】
第１のネットワークエンドポイントと第２のネットワークエンドポイントの間の通信のためにネットワークアセット（ｎｅｔｗｏｒｋ  ａｓｓｅｔｓ）を割り当てる方法であって、
ネットワークアセットのセットを通して該ネットワークエンドポイント間で呼の流れを開始するためのＳＩＰプロキシサーバにＳＩＰセッション初期化ｉｎｖｉｔｅを提供し、該呼の流れがアプリケーションサーバ上に常駐するアプリケーションを利用することと、
該セッション初期化ｉｎｖｉｔｅの結果として、ＳＩＰプロキシサーバからＳＩＰプロトコルマネージャに資源予約メッセージを提供し、該資源予約メッセージがウェブサービスインタフェースを介して提供されることと、
該ネットワークエンドポイントを接続する呼の流れ経路を作成するためにネットワークアセットを割り当てるために該ＳＩＰプロトコルマネージャを使用することと、
を備える方法。
【請求項２】
割り当てられる必要とされるネットワーク資源（ｎｅｔｗｏｒｋ  ｒｅｓｏｕｒｃｅｓ）の推定値を求めるために該セッション初期化ｉｎｖｉｔｅからＳＤＰ（セッション記述プロトコル）情報を抽出することをさらに含む請求項１に記載の方法。
【請求項３】
必要とされるネットワーク資源の該推定値がＱｏＳ情報を含む請求項２に記載の方法。
【請求項４】
ＰＣＭＭ（ＰａｃｋｅｔＣａｂｌｅ  Ｍｕｌｔｉｍｅｄｉａ）メッセージを介して該ＳＩＰプロトコルマネージャからポリシーサーバにネットワークアセットを割り当てるための要求を提供することをさらに含み、該ポリシーサーバが該ネットワークエンドポイントのためにネットワーク資源を割り当てる請求項１に記載の方法。
【請求項５】
該ポリシーサーバが、該第１のネットワークエンドポイントと関連する第１のポリシーサーバ及び該第２のネットワークエンドポイントと関連する第２のポリシーサーバとを含む請求項４に記載の方法。
【請求項６】
該ＳＩＰプロキシサーバが該第１のネットワークエンドポイントと関連する第１のＳＩＰプロキシサーバと、該第２のネットワークエンドポイントと関連する第２のＳＩＰプロキシサーバとを含む請求項１に記載の方法。
【請求項７】
該ＳＩＰプロトコルマネージャが、該第１のネットワークエンドポイントと関連する第１のＳＩＰプロトコルマネージャと、該第２のネットワークエンドポイントと関連する第２のＳＩＰプロトコルマネージャとを含む請求項１に記載の方法。
【請求項８】
ネットワークエンドポイントごとに、サポートされている媒体タイプごとの２つのＰＣＭＭゲートを作成することをさらに含み、該ＰＣＭＭゲートの１つが上り通信用であり、該ＰＣＭＭゲートの１つが下り通信用である請求項１に記載の方法。
【請求項９】
該ＳＩＰプロトコルマネージャが該ＳＩＰセッションを割り当てられている該ネットワーク資源のマッピングを維持し、それによって該アプリケーションサーバが該資源マッピングに対してセッションの状態を維持するニーズを抽出する請求項１に記載の方法。
【請求項１０】
少なくとも１つの追加ネットワークエンドポイントのためにネットワーク資源を割り当てることをさらに含み、該第１のネットワークエンドポイントが、呼の流れ経路を介して該第２のネットワークエンドポイント及び該少なくとも１つの追加のネットワークエンドポイントに通信する請求項１に記載の方法。
【請求項１１】
第１のネットワークエンドポイントと第２のネットワークエンドポイントの間の通信のためにネットワークアセットを割り当てるためのシステムであって、
ネットワークセットの該セットを通して該ネットワークエンドポイント間で、アプリケーションサーバ上のアプリケーションを利用する通信を開始するためのＳＩＰプロキシサーバと、
該セッション初期化ｉｎｖｉｔｅの結果として該ＳＩＰプロキシサーバから、ウェブサービスインタフェースを介して提供される資源予約メッセージを受信するためのＳＩＰプロトコルマネージャと、
を備え、該ＳＩＰプロトコルマネージャが該ネットワークエンドポイントを接続する呼の流れ経路を作成するためにネットワークアセットを割り当てるシステム。
【請求項１２】
該セッション初期化ｉｎｖｉｔｅがＳＤＰ情報を含み、該ＳＩＰプロトコルマネージャが、割り当てられるべき必要とされるネットワーク資源の推定値を求める請求項１１に記載のシステム。
【請求項１３】
必要とされるネットワーク資源の該推定値がＱｏＳ情報を含む請求項１２に記載のシステム。
【請求項１４】
該ＳＩＰプロトコルマネージャがＰＣＭＭメッセージを介してポリシーサーバにネットワークアセットを割り当てるための要求を提供し、該ポリシーサーバが該ネットワークエンドポイントのためにネットワーク資源を割り当てる請求項１１に記載のシステム。
【請求項１５】
該ポリシーサーバが該第１のネットワークエンドポイントと関連する第１のポリシーサーバと、該第２のネットワークエンドポイントと関連する第２のポリシーサーバとを含む請求項１４に記載の方法。
【請求項１６】
該ＳＩＰプロキシサーバが、該第１のネットワークエンドポイントと関連する第１のＳＩＰプロキシサーバと、該第２のネットワークエンドポイントと関連する第２のＳＩＰプロキシサーバとを含む請求項１１に記載のシステム。
【請求項１７】
該ＳＩＰプロトコルマネージャが、該第１のネットワークエンドポイントと関連する第１のＳＩＰプロトコルマネージャと、該第２のネットワークエンドポイントと関連する第２のＳＩＰプロトコルマネージャとを含む請求項１１に記載のシステム。
【請求項１８】
該ＳＩＰプロトコルマネージャが、ネットワークエンドポイントごとに、サポートされている媒体タイプごとの２つのＰＣＭＭゲートを作成し、該ＰＣＭＭゲートの１つは上り通信用であり、該ＰＣＭＭゲートの１つは下り通信用である請求項１１に記載のシステム。
【請求項１９】
該ＳＩＰプロトコルマネージャが、割り当てられるネットワーク資源を監視し、該ネットワークエンドポイント間の該通信の状態を維持し、それによって該アプリケーションサーバから該通信の該状態を抽出する請求項１１に記載の方法。
【請求項２０】
少なくとも１つの追加のネットワークエンドポイントをさらに含み、ＳＩＰプロトコルマネージャが該少なくとも１つの追加のネットワークエンドポイントのためにネットワーク資源を割り当て、該第１のネットワークエンドポイントが、呼の流れ経路を介して該第２のネットワークエンドポイント、及び該少なくとも１つの追加のネットワークエンドポイントに通信する請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概してポリシーに基づいたネットワーク資源管理に関する。
【０００２】
（関連出願の相互参照）
本願は、以下の特許出願の利点を主張する。つまり、２００５年５月１６日に出願された米国仮特許出願、出願番号第６０／６８１，３２９号。
【背景技術】
【０００３】
概して、ポリシーサーバが一式の規則、つまりポリシーに従ってネットワークアセットを管理する。単にネットワーク資源を（例えば、ルータＡからルータＢに）分割するに過ぎないポリシーサーバもあるが、アプリケーションをベースにしたポリシーサーバはある特定のアプリケーションに関してネットワークアセットを管理する。例えば、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）アプリケーションでは、２つのネットワークエンドポイントは該ネットワークを介して互いとＶｏＩＰ呼を確立することを希望してよい。ネットワークエンドポイントは、ＶｏＩＰ呼についてポリシーサーバからネットワークアセットを要求する。ポリシーサーバは、ポリシーに関連する情報を該要求から抽出し、ネットワークアセットを相応して割り当てる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
図１は、このＶｏＩＰの例を実現するための１つの方法を示している。第１のネットワークエンドポイント１０は、ＩＰネットワーク１４を介して第２のネットワークエンドポイント１２に対するＶｏＩＰ呼を確立することを希望する。第１のネットワークエンドポイント１０は、第１のアクセスネットワーク１６を通してＩＰネットワーク１４に接続し、第２のネットワークエンドポイントはは第２のアクセスネットワーク１８を通してＩＰネットワーク１４に接続する。他のプロトコルが使用されてよいが、第１のエンドポイント１０はアプリケーションサーバ２０に対し、この例の場合セッション初期化プロトコル（ＳＩＰ）を使用して要求１６を介してネットワークアセットを要求する。アプリケーションサーバ２０は、エンドポイントが呼を実現するために使用するＶｏＩＰアプリケーションをホストする。アプリケーションサーバ２０はＶｏＩＰ呼に対するＳＩＰ要求をポリシーサーバ２２に中継する。アプリケーションサーバ２０は、ポリシーサーバ２２を通して、ＶｏＩＰ呼を実現するために必要なアクセスネットワーク１６と１８での特定のサービスの質（ＱｏＳ）レベルの準備をする。
【０００５】
前述された準備は、呼に含まれる根本的なネットワーク資源のすべてとともに、アプリケーションサーバ１８がＳＩＰ呼の状態を維持する（つまり該呼と関連付けられたアクションの経過を追う）ことを必要とする。したがって、アプリケーションサーバ１８は「ステートフル」であることが必要とされる。
【課題を解決するための手段】
【０００６】
一態様では、第１のネットワークエンドポイントと第２のネットワークエンドポイントの間の通信にネットワークアセットを割り当てる方法は、ネットワークアセットのセットを通してネットワークエンドポイント間で呼の流れを開始するためのＳＩＰプロキシサーバにＳＩＰセッション初期化ｉｎｖｉｔｅを提供することを含む。該呼の流れはアプリケーションサーバに常駐するアプリケーションを利用する。該方法はさらに、該セッション初期化ｉｎｖｉｔｅの結果としてＳＩＰプロキシサーバからＳＩＰプロトコルマネージャに資源予約メッセージを提供することをさらに含む。資源予約メッセージはウェブサービスインタフェースを介して提供される。方法は、ネットワークエンドポイントを接続する呼のフロー経路を作成するためにネットワークアセットを割り当てるためにＳＩＰプロトコルマネージャを使用することも含む。
【０００７】
一実施形態は、割り当てられるべき必要とされるネットワーク資源の推定値を求めるためにセッション初期化ｉｎｖｉｔｅからのＳＤＰ情報を使用して抽出することをさらに含む。必要とされているネットワーク資源の推定値は例えばＱｏＳ情報を含む。
【０００８】
一実施形態は、ＰＣＭＭメッセージを介して該ＳＩＰプロトコルマネージャからポリシーサーバにネットワークアセットを割り当てるための要求を提供することをさらに含む。ポリシーサーバは、ネットワークエンドポイントのためにネットワーク資源を割り当てる。ポリシーサーバは、例えば、第１のネットワークエンドポイントと関連付けられる第１のポリシーサーバと、該第２のネットワークエンドポイントと関連付けられる第２のポリシーサーバとを含んでよい。
【０００９】
別の実施形態では、ＳＩＰプロキシサーバは、第１のネットワークエンドポイントと関連する第１のＳＩＰプロキシサーバと、第２のネットワークエンドポイントと関連する第２のＳＩＰプロキシサーバを含む。別の実施形態では、ＳＩＰプロトコルマネージャは、第１のネットワークエンドポイントと関連する第１のＳＩＰプロトコルマネージャを含み、第２のネットワークエンドポイントと関連する第２のＳＩＰプロトコルマネージャを含む。
【００１０】
一実施形態は、さらにサポートされている媒体タイプごとに２つのＰＣＭＭゲートを、ネットワークエンドポイントごとに作成することを含む。ＰＣＭＭゲートの１つは上り通信用であり、ＰＣＭＭゲートの１つは下り通信用である。
【００１１】
一実施形態では、ＳＩＰプロトコルマネージャは、ＳＩＰセッションが割り当てられているネットワーク資源のマッピングを維持し、それによって資源マッピングにセッションの状態を維持するためにアプリケーションサーバに対するニーズを抽出する。
【００１２】
別の実施形態は、さらに少なくとも１つの追加のネットワークエンドポイントにネットワーク資源を割り当てることを含む。第１のネットワークエンドポイントは、呼の流れ経路を介して第２のネットワークエンドポイントと、該少なくとも１つの追加のネットワークエンドポイントに通信する。
【００１３】
別の態様では、第１のネットワークエンドポイントと第２のネットワークエンドポイント間の通信のためにネットワークアセットを割り当てるためのシステムが、ネットワークアセットのセットを通してネットワークエンドポイント間の通信を開始するためのＳＩＰプロキシサーバを含む。該通信はアプリケーションサーバに常駐するアプリケーションを利用する。該システムはセッション初期化ｉｎｖｉｔｅの結果としてＳＩＰプロキシサーバから資源予約メッセージを受信するためのＳＩＰプロトコルマネージャも含む。資源予約メッセージはウェブサービスインタフェースを介して提供される。ＳＩＰプロトコルマネージャは、ネットワークエンドポイントを接続する呼流れ経路を作成するためにネットワークアセットを割り当てる。
【００１４】
一実施形態では、セッション初期化ｉｎｖｉｔｅはＳＤＰ情報を含み、ＳＩＰプロトコルマネージャは割り当てられるべき必要とされるネットワーク資源の推定値を求める。必要とされるネットワーク資源の推定値は、例えばＱｏＳ情報を含む。
【００１５】
別の実施形態では、ＳＩＰプロトコルマネージャは、ＰＣＭＭメッセージを介してポリシーサーバにネットワークアセットを割り当てるための要求を提供し、ポリシーサーバはネットワークエンドポイントのためにネットワーク資源を割り当てる。
【００１６】
一実施形態では、ポリシーサーバは第１のネットワークエンドポイントと関連する第１のポリシーサーバと、第２のネットワークエンドポイントと関連する第２のポリシーサーバとを含む。別の実施形態では、ＳＩＰプロキシサーバは第１のネットワークエンドポイントと関連する第１のＳＩＰプロキシサーバと、第２のネットワークエンドポイントと関連する第２のＳＩＰプロキシサーバを含む。
【００１７】
一実施形態では、ＳＩＰプロトコルマネージャは、第１のネットワークエンドポイントと関連する第１のＳＩＰプロトコルマネージャと、第２のネットワークエンドポイントと関連する第２のＳＩＰプロトコルマネージャを含む。別の実施形態では、ＳＩＰプロトコルマネージャが、ネットワークエンドポイントごとに、サポートされている媒体タイプごとに２つのＰＣＭＭゲートを作成し、ＰＣＭＭゲートの１つは上り通信用であり、ＰＣＭＭゲートの１つは下り通信用である。
【００１８】
一実施形態では、ＳＩＰプロトコルマネージャはＳＩＰセッションを割り当てられているネットワーク資源のマッピングを維持し、それによってアプリケーションサーバが資源マッピングに対してセッションの状態を維持するニーズを抽出する。
【００１９】
別の実施形態は、少なくとも１つの追加のネットワークエンドポイントをさらに含み、ＳＩＰプロトコルマネージャは該少なくとも１つの追加のネットワークエンドポイントのためにネットワーク資源を割り当て、第１のネットワークエンドポイントは呼の流れ経路を介して第２のネットワークエンドポイント及び少なくとも１つの追加のネットワークエンドポイントに通信する。
【発明を実施するための最良の形態】
【００２０】
説明されている実施形態は、ネットワークを介して通信することを希望するネットワークエンドポイントのために、アクセスネットワーク内でＱｏＳ資源を確立する、維持する、及び終端するためにＱｏＳが有効にされたＳＩＰプロキシサーバと連動してＳＩＰプロトコルモジュール（ＳＩＰ  ＰＭ）を使用するネットワークアーキテクチャである。ＳＩＰ  ＰＭは、アプリケーションサーバから離れてＳＩＰ通信セッションを実現するために必要な手順及び機能性を抽出し、その結果アプリケーションサーバはそれらのセッションの複雑さと関連を持っている必要はない。
【００２１】
これらの概念は、ビデオストリーミング、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）通信、及びネットワーク化されたゲーミング等の他の応用例にも適用できるが、この実施形態は、高品質テレビ会議セッションを実現する２つのエンドポイントを説明する。
【００２２】
図２は、第１のネットワークエンドポイント１００、第２のネットワークエンドポイント１０２、ＩＰネットワーク１０４、第１のアクセスネットワーク１０６、及び第２のアクセスネットワーク１０８を含む説明されている実施形態を示す。この実施形態では、第１のネットワークエンドポイント１００は、アクセスネットワーク１０６、１０８及びＩＰネットワーク１０４を通して第２のネットワークエンドポイント１０２とテレビ会議セッションを実現する。
【００２３】
図２の実施形態は、第１のＳＩＰプロキシサーバ１１０と、第１のＳＩＰプロトコルモジュール（ＳＩＰ  ＰＭ）１１２と、第１のポリシーサーバ１１４とをさらに含む。これらの３つの構成要素は、第１のネットワークエンドポイント１００のために、第１のアクセスネットワーク１０６内にＱｏＳ資源を確保し、維持するためにともに動作する。
【００２４】
図２の実施形態は、第２のＳＩＰプロキシサーバ１１６と、第２のＳＩＰプロトコルモジュール（ＳＩＰ  ＰＭ）１１８と、第２のポリシーサーバ１２０とも含む。これらの３つの構成要素は、第２のネットワークエンドポイント１０２のために第２のアクセスネットワーク１０８内にＱｏＳ資源を確保し、維持するためにともに動作する。これらの３つの構成要素の動作は、後述されるように、第１のネットワークエンドポイント１００と関連する対応する構成要素の動作と本来同一である。
【００２５】
アプリケーションサーバ１２２は、ネットワークエンドポイント１００、１０２が呼を実現するために使用するテレビ会議アプリケーションをホストする。
【００２６】
第１のＳＩＰプロキシサーバ１１６は、シンプルオブジェクトアクセスプロトコル／拡張マークアップ原語（ＳＯＡＰ／ＸＭＬ）アプリケーションプログラミングインタフェース（ＡＰＩ）を介してＳＩＰ  ＰＭと通信する。このインタフェースは本書ではウェブサービスインタフェース（ＷＳＩ）とも呼ばれている。ＳＯＡＰ／ＸＭＬＡＰＩによって、ＲＦＣ  ３２６４（「セッション記述プロトコル（ＳＤＰ）によるオファー／アンサーモデル」）、ＩＥＴＦ  ＲＦＣ  ３２６４）に定義されるように、呼セットアップオファー及び回答に含まれているセッション記述プロトコル（ＳＤＰ）パラメータに基づいて、ＳＩＰプロキシサーバ１１６が、アクセスネットワーク１０６内のＱｏＳ要件を要求できるようにする。ＳＩＰ  ＰＭ１１２は、ポリシーサーバ１１４にそれらの要件を通信するためにＣａｂｌｅＬａｂｓ  ＰａｃｋｅｔＣａｂｌｅ  Ｍｕｌｔｉｍｅｄｉａ（ＰＣＭＭ）プロトコル（ＰＫＴ−ＴＲ−ＭＭ−ＡＲＣＨ−Ｖ０１−０３０６２７、Ｖ０１、２００３年６月２３日）を使用する。
【００２７】
テレビ会議セッションを確立するために、第１のネットワークエンドポイント１００は、そのセッションをセットアップする意図を伝えるために第２のネットワークエンドポイント１０２に信号で伝達を試みる。第１のネットワークエンドポイント１００は「ＩＮＶＩＴＥ」メッセージをそのＳＩＰプロキシサーバ１１０に送信する。次に、第１のＳＩＰプロキシサーバ１１０が、第１のネットワークエンドポイント１００のために第１のＳＩＰ  ＰＭを介して資源を予約するためにＳＯＡＰ／ＸＭＬ  ＡＰＩを呼び出し、第２のネットワークエンドポイント１０２の領域に「ＩＮＶＩＴＥ」メッセージを転送する。第２のネットワークエンドポイントの領域内のポリシーサーバ１１４は必要なネットワーク資源を割り当てる。割り当てられたネットワーク資源はＱｏＳを含んでよい。
【００２８】
いったん「ＩＮＶＩＴＥ」が第２のネットワークエンドポイント１０２に関連付けられる第２のＳＩＰプロキシサーバ１１６に達すると、第２のＳＩＰプロキシサーバ１１６は、資源が第２のネットワークエンドポイント１０２のためにポリシーサーバ１２０を通して予約される必要がある旨を第２のＳＩＰ  ＰＭ１１８に信号で知らせる。この予約は、当初、第１のネットワークエンドポイント１００のＳＤＰ（つまり、オファー）を使用して必要とされる資源の推定値に基づいている。次に、「ＩＮＶＩＴＥ」は第２のネットワークエンドポイント１０２に転送される。
【００２９】
第２のネットワークエンドポイント１０２が呼に応えると、「２００  ＯＫ」メッセージが第１のネットワークエンドポイント１００に送り返される。このプロセスの間、両方の領域のＳＩＰプロキシサーバ１１０、１１６は、第２のネットワークエンドポイント１０２のＳＤＰ（つまりアンサー）に基づいて要件のあらゆる変化を反映するために修正される、前もって予約されたＱｏＳをコミットする。
【００３０】
各ＳＩＰ  ＰＭ１１２、１１８は、ＳＤＰメッセージを解析し、媒体タイプ、媒体コーデック、ソースＩＰアドレスと宛先ＩＰアドレス、及びポートを含む関連する媒体情報を読み取って、両方のＵＡのためのＳＤＰメッセージを解釈し、次にそのそれぞれのネットワークエンドポイントのためにＰＣＭＭ「ＧａｔｅＳｅｔ」メッセージを策定する。
【００３１】
この実施形態では、セッションに関与するネットワークエンドポイントの少なくとも１つがそのプロキシサーバの責任である場合に、各ＳＩＰプロキシサーバ（１１０、１１６）がそのそれぞれのＳＩＰ  ＰＭ（１１２、１１８）と通信することに関与する。セッションに関与するネットワークエンドポイントを担当しない信号伝達経路に沿った仲介プロキシは、ＳＩＰ  ＰＭと通信することを必要とされない。各ＳＩＰプロキシは、両方ともがネットワークエンドポイントの機能を完全に確かめるために必要とされるので、そのそれぞれのＳＩＰ  ＰＭをオファーとアンサーとともに信号で知らせる。
【００３２】
ネットワークエンドポイントごとに、関連付けられるＳＩＰ  ＰＭは、１つは上り方向で、１つは下り方向の、媒体タイプごとに２つのＰＣＭＭゲートを作成する。説明されている実施形態では、ネットワークエンドポイント１００、１０２はＳＩＰテレビ電話である。これらのネットワークエンドポイントのためのＳＤＰは、音声とビデオという２つの媒体タイプを含むことができる。ネットワークエンドポイントごとに、ＳＩＰ  ＰＭはこのようにして以下の合計４つのＰＣＭＭゲートを作成する。
・音声のための上りゲート
・音声のための下りゲート
・ビデオのための上りゲート
・ビデオのための下りゲート
【００３３】
セッションが終了すると、終了側ネットワークエンドポイントが「ＢＹＥ（さようなら）」メッセージをそれらの関連するＳＩＰプロキシサーバを通して他のネットワークエンドポイントに送信する。「ＢＹＥ」メッセージが各プロキシサーバを通って横断するにつれて、そのプロキシサーバはＳＩＰ  ＰＭにリリースＱｏＳメッセージを送信する。リリースＱｏＳメッセージは、セッションセットアップの間に作成されたゲートのためにＰＣＭＭ  ＧａｔｅＤｅｌｅｔｅｓを送信し、ネットワークエンドポイントのために早期にセットアップされたサービスフローを除去する。
【００３４】
ＳＯＡＰ／ＸＭＬ  ＡＰＩ仕様；
説明されている実施形態のためのＳＩＰ  ＰＭのＡＰＩ特性は、（１）ＡＰＩ戻り状態コード、（２）ＰａｒｔｙＩｎｆｏパラメータタイプ、及び（３）ＡＰＩ関数という点で後述される。ＳＯＡＰ／ＸＭＬ  ＡＰＩは、二相だけではなく単相の予約／コミット機能性も提供する。オペレータが運転モードを制御するが、デフォルトによって、資源がケーブルモデム終端システム（ＣＭＴＳ）上で「予約され」、次に被呼者が応答すると「コミットされる」二相コミットモードで動作する。
【００３５】
ＡＤＩ戻り状態コード；
図３に示されている表は、ＳＩＰ  ＰＭによって返される、考えられるエラーコードを説明している。状態コードは、成功または失敗、及びＡＰＩ動作の失敗の理由を示すために使用される。
【００３６】
他の実施形態は、例えば、ゲート動作を失敗させる特定の媒体回線を特定するために、失敗した動作にとって必要とされる追加の詳細を含む。この情報は、サブコードとして、あるいは追加コードとして図３に示されているコードの一つに返すことができるであろう。
【００３７】
ＰａｒｔｙＩｎｆｏパラメータタイプ；
ＰＣＭＭ内で、及びＣＭＴＳ上で、媒体流れのためのＱｏＳ情報がゲートと呼ばれているオブジェクトの中で伝達される／記憶される。ゲートは、アクティブケーブルモデムまたはカスタマにより提供される装置（ＣＰＥ）ＩＰアドレスのどちらかである、加入者識別子と関連付けられる。ＣＭＴＳと加入者のケーブルモデムは、トラフィック分類子を使用することによってゲートと関連付けられている流れの上にトラフィックをフィルタにかける。分類子は、ソースＩＰアドレスと宛先ＩＰアドレス及びポートを指定することによって設定される。
【００３８】
ＳＩＰ  ＰＭ  ＡＰＩ内では、ＳＩＰセッションのエンドポイントを説明するパラメータが、企業方針の実行、及び料金請求書作成発行イベントの生成で使用される情報を提供するためだけではなく、ＰＣＭＭゲートを構成するためにも使用される。このパラメータは、オブジェクトクラス「ＰａｒｔｙＩｎｆｏ」として定義され、以下のフィールドを含む。
ＰａｒｔｙＩｎｆｏ｛
ｓｔｒｉｎｇ  ｉｄ；
ｓｔｒｉｎｇ  ｓｄｐ；
ｂｏｏｌｅａｎ  ｑｏｓＥｎａｂｌｅｄ；
ｓｔｒｉｎｇ  ｉｐＡｄｄｒｅｓｓ
｝
【００３９】
これらのパラメータのそれぞれは以下のように定義される。
【００４０】
ｉｄ：これは、加入者のための一意の識別子である。そのフォーマットは、ｕｓｅｒ＠ｄｏｍａｉｎ（つまり、ａｌｉｃｅ＠ｃｏｍｃａｓｔ．ｎｅｔ）である。このｉｄは電話をかけるとき／受信するときに加入者がどの位置にあるのかに関係なく、ある特定の加入者にとって同じでなければならない。このフィールドが空である場合は、（ＳＩＰ  ＰＭがＲＦＣ  ２３２７［セッション記述プロトコル：ＩＥＴＦ  ＲＦＣ２３２７］の中に定義されているように関係者のセッション記述を一意に特定できるようにする）ＳＤＰが存在する限り、このＰａｒｔｙＩｎｆｏは依然として受け入れられる。この識別子は、ダイアログのために第１のＡＰＩ呼で提供される必要があるにすぎない。このフィールドは例えば移動するユーザのために使用される。
【００４１】
ｓｄｐ：これはオファー／アンサーに含まれるＳＤＰである。使用できない場合、このフィールドはデフォルトで空の文字列になる。
【００４２】
ｑｏｓＥｎａｂｌｅｄ：これは、ＳＩＰ  ＰＭに、この関係者がＥＰの責任領域内にあるかどうか、及びそれが（ＥＰの観点から）ＱｏＳが有効にされた関係者であるかどうかを知らせるブールのフラグ（つまり、真／偽）である。例えば、ゲストの場合、このフラグは偽に設定され、同様にＥＰの責任領域内にない関係者の場合も、このフラグは偽になる。いったんこのフラグがセッションの中で真に設定されると、それはセッションの残りの間、真のままとなる。
【００４３】
ｉｐＡｄｄｒｅｓｓ：これは呼を開始する／受信する関係者のＩＰアドレス（点線の１０進表記）である（このパラメータは、ＳＤＰが使用できないケースだけでＰＣＭＭメッセージ専用の加入者ｉｄフィールドに使用できるであろう）。使用できない、あるいは必要とされない（つまり、ＳＤＰ内に十分な情報がある）場合、このフィールドはデフォルトの空の文字列になる必要がある。
【００４４】
多くのセッションエンドポイントについての情報を必要とする関数の場合、ＰａｒｔｙＩｎｆｏオブジェクトのアレイが提供される必要がある。
【００４５】
ＡＰＩ関数；
以下の説明は、ＱＢＵＳ  ＳＩＰ  ＰＭによって露呈されるＳＯＡＰ／ＸＭＬ  ＲＰＣインタフェースの詳細を提供する。
【００４６】
ｉｎｔ  ｒｅｓｅｒｖｅＱｏｓ；――ＳＩＰプロキシサーバがＳＩＰ  ＩＮＶＩＴＥメッセージを受信するときにこの方法が呼び出され、アクセスネットワーク内で最初に資源を予約するためにＳＩＰ  ＰＭによって使用され、最終的に呼ばれるネットワークエンドポイントが呼に応えるときにそれらの資源が使用可能であることを保証する。オペレータが、関連するＱｏＳ資源（つまり、構成可能なオプション）を有さない呼を阻止することを望むケースでＱｏＳが使用できない場合、このインタフェースを使用して、ＳＩＰプロキシサーバは発呼者に信号を送り返す機会を有する。
【００４７】
以下はこの関数に適切な構文及びパラメータを提供する。
ｉｎｔ  ｒｅｓｅｒｖｅＱｏｓ（
ｓｔｒｉｎｇ  ｓｅｓｓｉｏｎＩｄ，
ＰａｒｔｙＩｎｆｏ［］ｐａｒｔｉｅｓ，
ｂｏｏｌｅａｎ  ｅ９１１）
パラメータ：
ＳｅｓｓｉｏｎＩｄ；――呼−ｉｄ  ＳＥＭＩＣＯＬＯＮ（セミコロン）ｆｒｏｍ（から）−タグ［ＳＥＭＩＣＯＬＯＮ  ｔｏ（へ）−タグ］
呼−ｉｄ、ｆｒｏｍ−タグ及びｔｏ−タグが、対応するＳＩＰヘッダフィールドから抽出されなければならない。ｔｏ−タグがＳＩＰメッセージの中に存在していない場合、ＳｅｓｓｉｏｎＩｄは呼ｉｄとｆｒｏｍ−タグを含むだけである。ｔｏ−タグとｆｒｏｍ−タグは（どのエンドポイントが要求を発行しているのかに応じて）逆転できるため、ＳｅｓｓｉｏｎＩｄを同じ呼ｉｄと同じ（ｆｒｏｍ−タグ、ｔｏ−タグ）組と一致させるのはＳＩＰ  ＰＭの責任である。例えば、２つの次のＳｅｓｓｉｏｎＩｄが同等である。
１２３４５６−００ｅ０９５３４３１＠１５１．１０４．２．３；５９０４３２；２７６４３９  
１２３４５６−００ｅ０９５３４３１＠１５１．１０４．２．３；２７６４３９；５９０４３２
ｐａｒｔｉｅｓ；――前項で説明されたような呼の関係者に関する情報を含むアレイ。
ｅ９１１；――この呼が緊急呼であるかどうかを示すブールフラグ。ＳＩＰ  ＰＭは、（それが他の既存の呼では確立されたＱｏＳを削除しなければならない場合にも）予約がこれらのタイプの呼について成功することを確認する。デフォルトにより、このフラグは偽である。それは説明されている筋書きでは「偽」と仮定されるので、文書の残りでは言及されていない。
戻り値：  状態コード
【００４８】
ｉｎｔ  ｃｏｍｍｉｔＱｏｓ――被呼者が応答し、終端側プロキシサーバが２００ＯＫを受信すると、それは被呼者ＳＤＰを含むＳＩＰ  ＰＭに対してｃｏｍｍｉｔＱｏｓ（）要求を送信する。この段階で、ＳＩＰ  ＰＭはそれが必要とするすべての情報を有し、分類子及びＱｏＳ資源を調整するだけではなく、ＰＣＭＭゲートの状態を、予約済みからコミット済みに変更することによって資源をコミットする。その資源が呼開始段階で予約されたと考えると、資源のコミットメントは（コミットされた資源が確保された資源を超えない限り）成功するはずである。
【００４９】
以下は、適切な構文とパラメータをこの関数に提供する。
ｉｎｔ  ｃｏｍｍｉｔＱＯｓ（
ｓｔｒｉｎｇ  ｓｅｓｓｉｏｎＩｄ，
ＰａｒｔｙＩｎｆｏ［］ｐａｒｔｉｅｓ）
パラメータ：
ＳｅｓｓｉｏｎＩｄ：呼−ｉｄ  ＳＥＭＩＣＯＬＯＮ  ｆｒｏｍ−タグ［ＳＥＭＩＣＯＬＯＮ  ｔｏ−タグ］
呼ｉｄ、ｆｒｏｍ−タグ、及びｔｏ−タグは、対応するＳＩＰヘッダフィールドから抽出されなければならない。ｔｏ−タグがＳＩＰメッセージに存在しない場合、ＳｅｓｓｉｏｎＩｄは呼ｉｄとｆｒｏｍ−タグだけを含む。ｔｏ−タグとｆｒｏｍ−タグは（どのエンドポイントが要求を発行しているのかに応じて）逆転できるため、ＳｅｓｓｉｏｎＩｄを同じ呼ｉｄと同じ（ｆｒｏｍ−タグ、ｔｏ−タグ）組と一致させることはＳＩＰ  ＰＭの責任である。例えば、２つの次のＳｅｓｓｉｏｎＩｄが同等である。
１２３４５６−００ｅ０９５３４３１  ＠１５１．１０４．２．３；５９０４３２；２７６４３９  
１２３４５６−００ｅ０９５３４３１＠１５１．１０４．２．３；２７６４３９；５９０４３２
ｐａｒｔｉｅｓ；――前記に定義されたとおりのアレイ（このケースでは、それは被呼者の情報を含む）。本書に説明されているすべてのケースではそれは長さ１のアレイであるが、それはアレイとして定義されている。その理由は、アレイが、このインタフェースが連続ユーザエージェントとＳＩＰ  ＰＭの間にあり、連続ユーザエージェントが１つのＡＰＩ呼の複数の関係者についての情報を提供することを望むためである。
戻り値：  状態コード
【００５０】
ｉｎｔ  ｒｅｌｅａｓｅＱｏｓ；――この関数は、指定されているセッションのためのすべてのＱｏＳ資源を解放する。通常、この関数は、ＳＩＰプロキシがＢＹＥメッセージをエンドポイントの１つから受信するときに呼び出される。
【００５１】
以下は、この関数に適切な構文とパラメータを提供する。
ｉｎｔ  ｒｅｌｅａｓｅＱｏｓ（
ｓｔｒｉｎｇ  ｓｅｓｓｉｏｎｌｄ）
パラメータ：
ＳｅｓｓｉｏｎＩｄ；――前記ｒｅｌｅａｓｅＱｏｓ（）メソッド呼及びｃｏｍｍｉｔＱｏｓ（）メソッド呼で使用されるｓｅｓｓｉｏｎＩｄ
戻り値：  状態コード
【００５２】
ｓｔｒｉｎｇ  ｇｅｔＶｅｒｓｉｏｎ；――この関数はＱＢＵＳ  ＳＩＰ  ＰＭのバージョン文字列を返す。以下は、この関数に適切な構文とパラメータを提供する。
ｓｔｒｉｎｇ  ｇｅｔＶｅｒｓｉｏｎ（）
パラメータ：  Ｎｏｎｅ
戻り値：  バージョン文字列
【００５３】
呼の流れの例；
図４から図１４は、オンネット、オフネット、呼保留、再ｉｎｖｉｔｅ、分岐呼、及び３ＰＣＣシナリオのためのＳＩＰ呼の流れを示している。それぞれの呼の流れは、ＳＩＰ  ＰＭ  ＡＰＩ呼だけではなく、ＳＩＰメッセージ交換も示す。
【００５４】
図４Ａ及び図４Ｂは、オンネットの成功した呼の例示的な呼の流れ図を示す。この図では、図２に示されている構成要素との対応は以下の通りである。つまり、「発呼者」は第１のネットワークエンドポイント１００に相当し、「被呼者」は第２のネットワークエンドポイント１０２に相当し、「ＥＰ１」は第１のＳＩＰプロキシサーバ１１０に相当し、「ＥＰ２」は第２のＳＩＰプロキシサーバ１１６に相当し、「ＳＩＰＰＭ１」は第１のＳＩＰ  ＰＭ１１２に相当し、「ＳＩＰＰＭ２」は第２のＳＩＰ  ＰＭ１１８に相当する。
【００５５】
図５は、オンネットの成功しなかった呼の例示的な呼の流れ図を示す。図２に示されている構成要素との対応は、図４Ａ及び図４Ｂについて前述された対応と同じである。
【００５６】
図６は、オフネット（つまり、公衆交換電話網−ＰＳＴＮ）呼の例示的な呼の流れ図を示している。この呼の流れの例は、早期ダイアログが作成される発信ＰＳＴＮ呼を示している。図２に示されている構成要素との対応は図４Ａ及び図４Ｂについて前述される対応と同じである。
【００５７】
図７は、呼が接続された後の呼保留の例示的な呼流れ図を示している。図２に示されている構成要素との対応は図４Ａ及び図４Ｂについて前述された対応と同じである。この例では、呼保留が接続された後、発呼者は呼を保留にし、発呼者はＳＤＰ３のセッションレベルで「ａ＝ｓｅｎｄｏｎｌｙ」属性でｒｅ−ＩＮＶＩＴＥを送信することになる。呼を保留するための別の方法は、接続フィールドの０．０．０．０アドレスであろう。応答で、被呼者は、セッションレベルで「ａ＝ｒｅｃｖｏｎｌｙ」属性を含むＳＤＰ４で応答する。「ａ＝ｓｅｎｄｏｎｌｙ」属性は媒体レベルとなり、そのケースではそれは、それが属している媒体だけに影響を及ぼすことに留意する。
【００５８】
図８、図９及び図１０は、ｒｅ−ＩＮＶＩＴＥが、例えば媒体を追加／削除し、ＩＰアドレスを変更し、資源要件を増加／減少する呼の流れを描いている。図８は、媒体が無事に追加／削除されるときの例示的な呼の流れを示している。このケースでは、発呼者が被呼者をｒｅ−ＩＮＶＩＴＥすると、呼の流れ図は、媒体が初期のオファー／アンサーに関連して追加されるか、削除されるかのどちらかのケースを対象とする。図２に示されている構成要素との対応は、図４Ａ及び図４Ｂについて前述される対応と同じである。
【００５９】
図９は、媒体が無事に追加／削除されなかった例示的な呼の流れ図を示している。このケースでは、被呼者は「４８８」メッセージ（Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅ  Ｈｅｒｅ（ここでは受け入れ不可））を送信することによって新しいオファーを拒絶する。この例は、ＳＩＰ  ＰＭが両方のケース（つまり媒体の追加と削除）をどのように処理するのかを示している。図２で示されている構成要素との対応は、図４Ａ及び図４Ｂについて前述される対応と同じである。
【００６０】
図１０は、要求される追加の媒体がＱｏＳを許可されないときの例示的な呼の流れ図を示している。図２に示されている構成要素との対応は図４Ａ及び図４Ｂに前述される対応と同じである。ＩＰアドレス変更は（特別なケース（保留）または非公開（ＩＣＥに関する項を参照すること）に該当する、アドレスが０．０．０．０ではない限り）あらゆる媒体について起こる場合、関連するＳＩＰ  ＰＭは該媒体と関連するゲートを削除し、新しいアドレスとの新しいゲートを作成する。
【００６１】
図１１Ａ、図１１Ｂ、図１１Ｃ及び図１１Ｄは、分岐呼、つまり被呼者が２つの連絡先（ｃａｌｌｅｅ１とｃａｌｌｅｒ２）を有するときの例示的な呼の流れ図を示している。図２に示されている構成要素との対応は、第２の被呼者の追加を除き、図４Ａ及び図４Ｂについて前述される対応と同じである。
【００６２】
図１２Ａ及び図１２Ｂは、ＳＩＰ  ＰＭがＲＦＣ  ３７２５［セッション初期化プロトコル（ＳＩＰ）におけるサードパーティ呼の制御（３ｐｃｃ）のための現在の最良の実施例（Ｂｅｓｔ  Ｃｕｒｒｅｎｔ  Ｐｒａｃｔｉｃｅｓ  ｆｏｒ  Ｔｈｉｒｄ    Ｐａｒｔｙ  Ｃａｌｌ  Ｃｏｎｔｒｏｌ（３ｐｃｃ）ｉｎ  ｔｈｅ  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＩＰ）：ＩＥＴＦ  ＲＦＣ  ３７２５）］に説明されているように、どのようにして３ｐｃｃ呼の流れＩを処理するのかを説明している。この３ｐｃｃ呼の流れと、前述された項に説明されている呼の流れとの相違点は、オファーがＩＮＶＩＴＥの代わりに２００ＯＫで送信されるという点である。図２に示されている構成要素との対応は、ＲＦＣ  ３７２５仕様で必要とされているコントローラの追加を除き、図４Ａ及び図４Ｂについて前述される対応と同じである。
【００６３】
図１３Ａ及び図１３Ｂは、ＲＦＣ  ３７２５に説明されているようにＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩを処理するのかを説明している。図２に示されている構成要素との対応は、ＲＦＣ  ３７２５仕様で必要とされているコントローラの追加を除き、図４Ａ及び図４Ｂについて前述される対応と同じである。コントローラは、最初にＩＮＶＩＴＥを発呼者に送信する。これが、単一の音声媒体回線、１台のコーデック、ランダムポート番号（ただしゼロではない）、及び０．０．０．０という接続アドレスのオファー（ｓｄｐ１）を含む標準的なＩＮＶＩＴＥである。これは、どの媒体も発呼者から流れないため、「ブラックホール化される（ｂｌａｃｋ  ｈｏｌｅｄ）」初期媒体ストリームを生じさせる。
【００６４】
ｃａｌｌｅｒ１が（２）に応答すると、２００  ＯＫが、接続回線内の有効なアドレスの付いた応答ｓｄｐ２を含む。コントローラはＡＣＫ（４）を送信する。それは次に第２のＩＮＶＩＴＥ（３）を生成する。このＩＮＶＩＴＥは該被呼者にアドレス指定され、それは該被呼者に対するオファーとしてｓｄｐ２を含む。
【００６５】
このＩＮＶＩＴＥが該被呼者の電話を鳴らす。それが応答すると、それは応答、ｓｄｐ３付きの２００  ＯＫ（５）を生成する。コントローラは、次にＡＣＫ（６）を生成する。次に、それはｓｄｐ３をオファーとして含むｒｅ−ＩＮＶＩＴＥを発呼者（７）に送信する。
【００６６】
図１４Ａ、図１４Ｂ及び図１４Ｃは、ＲＦＣ３７２５に説明されているようにＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩＩを処理するのかを説明している。図２に示されている構成要素との対応は、ＲＦＣ  ３７２５仕様で必要とされているコントローラの追加を除き、図４Ａ及び図４Ｂについて前述される対応と同じである。第１に、コントローラはＩＮＶＩＴＥ（１）をＳＤＰなしで発呼者に送信する。該ＩＮＶＩＴＥは発呼者の電話を鳴らす。発呼者が応答すると、発呼者は、発呼者のオファー、ｏｆｆｅｒ１を含む２００ＯＫ（２）を生成する。コントローラは応答（３）を含む即座のＡＣＫを生成する。この応答は、その接続アドレスが０．０．０．０に等しい「ブラックホール」ＳＤＰである。
【００６７】
コントローラは、次にＩＮＶＩＴＥをＳＤＰ（４）なしで被呼者に送信する。これが被呼者の電話を鳴らす。被呼者が応答すると、被呼者は被呼者のオファー、ｏｆｆｅｒ２（５）を含む２００  ＯＫを送信する。このＳＤＰは、発呼者（６）にｒｅ−ＩＮＶＩＴＥを作成し直すために使用される。
【００６８】
発呼者からの２００  ＯＫ（７）のＳＤＰ、ａｎｓｗｅｒ２‘もａｎｓｗｅｒ２として発呼者（８）にＡＣＫの中でそれを送信する前に再編成される、あるいは切り取られる必要がある場合もある。最後に、ＡＣＫが発呼者（９）に送信され、次に媒体が流れることができる。
【００６９】
ＲＦＣ  ３７２５に説明されているように、３ｐｃｃ呼の流れＩＶの場合、ＳＩＰ  ＰＭは図１４Ａ、図１４Ｂ、及び図１４Ｃに示されている呼の流れＩＩＩと同様に流れを処理する。流れＩＶは流れの複雑さを削減する流れＩＩＩでの変動を含む。実際のメッセージフローは同一であるが、ＳＤＰの配置と構造は異なる。初期のＩＮＶＩＴＥ（１）は媒体をまったく含まないＳＤＰを含み、ｍ回線がないことを意味する。これは有効であり、セッションの媒体構成がｒｅ−ＩＮＶＩＴＥを通して後で確立されることを暗示している（セッション記述プロトコル：ＩＥＴＦ  ＲＦＣ２３２７を参照）。いったんＩＮＶＩＴＥが受信されると、発呼者は警告される。発呼者が呼に応答すると、２００  ＯＫ（２）はやはり媒体がない応答を有する。呼のコントローラは応答（３）を肯定応答する。この点以降の流れは、図１４Ａ、図１４Ｂ及び図１４Ｃに説明されるように流れＩＩＩに同一である。
【００７０】
流れＩＩＩとの唯一の相違点は最初の３つのメッセージ内にあるため、ＳＩＭ  ＰＭとの対話はメッセージ３を超える流れＩＩＩと同じである。メッセージ３の前では、ＥＰがＩＮＶＩＴＥ（１）を受信すると、ＥＰはｒｅｓｅｒｖｅＱｏｓ要求をＩＮＶＩＴＥからコピーされるｓｄｐとともにＳＩＰ  ＰＭに送信する。ＳＤＰに媒体はないため、ＳＩＰ  ＰＭは該情報を保存するが、資源は予約しない。応答が受信されると（２）、媒体は存在しないためＳＩＰ  ＰＭは同様にその情報を更新するだけで、資源は予約しない。
【００７１】
ＩＣＥ対話；
現在のＩＣＥ草案［対話型接続性確立（ＩＣＥ）：マルチメディアセッション確立プロトコルのためのＮＡＴ考察（Ｉｎｔｅｒａｃｔｉｖｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＩＣＥ）：ＮＡＴ  Ｔｒａｖｅｒｓａｌ  ｆｏｒ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｅｓｓｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ｐｒｏｔｏｃｏｌｓ：ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ−０４を参照）に対する更新が、エンドポイントに選ばれた候補とｒｅ−ＩＮＶＩＴＥを送信し、それを「ｃ＝」回線の中に格納することを命じることを考えると、ＳＩＰ  ＰＭは、ＩＣＥ［６］によって導入される新しいＳＤＰ［４］属性（「候補」）を理解する必要はない。
【００７２】
ｒｅ−ＩＮＶＩＴＥにおいて、アドレスが（初期のオファー／アンサー交換で提供される初期のアドレスと異なるであろう）非公開アドレスである場合、ＳＩＰ  ＰＭは、それがＩＰアドレス変更を伴うｒｅ−ＩＮＶＩＴＥについて行うようにあらゆる作成されたゲートを削除する。また、新しいアドレスが非公開であることを考えると、それは新しいゲートを作成しない。
【００７３】
本発明は、その精神または本質的な特徴から逸脱することなく他の特定の形式で具現化されてよい。したがって、本実施形態は制限的ではなく、実例となるとして検討されるべきであり、本発明の範囲は前記説明によってよりもむしろ添付請求項によって示されるため、請求項の同等性の意味と範囲内になるすべての変更はその中に包含されることを意図される。
【図面の簡単な説明】
【００７４】
【図１】２つのネットワークエンドポイント間でＶｏＩＰリンクを確立するための従来の技術のアーキテクチャを示す。
【図２】ネットワークエンドポイント間の通信のためにネットワークアセットを割り当てるための説明された実施形態を示す。
【図３】説明された実施形態におけるＳＩＰ  ＰＭによって返される、考えられるエラーコードを示す。
【図４Ａ】オンネットの成功した呼のための例示的な呼の流れ図を示す。
【図４Ｂ】オンネットの成功した呼のための例示的な呼の流れ図を示す。
【図５】オンネットの成功しなかった呼の例示的な呼の流れ図を示す。
【図６】オフネットの呼の例示的な呼の流れ図を示す。
【図７】呼が接続された後の、呼の保留の例示的な呼の流れ図を示す。
【図８】媒体が無事に追加／削除されたときの例示的な呼の流れ図を示す。
【図９】媒体が無事に追加／削除されなかったときの例示的な呼の流れ図を示す。
【図１０】要求されている追加の媒体がＱｏＳを許可されないときの例示的な呼の流れ図を示す。
【図１１Ａ】分岐した呼の例示的な呼の流れ図を示す。
【図１１Ｂ】分岐した呼の例示的な呼の流れ図を示す。
【図１１Ｃ】分岐した呼の例示的な呼の流れ図を示す。
【図１１Ｄ】分岐した呼の例示的な呼の流れ図を示す。
【図１２Ａ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩを処理するのかを説明する。
【図１２Ｂ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩを処理するのかを説明する。
【図１３Ａ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩを処理するのかを説明する。
【図１３Ｂ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩを処理するのかを説明する。
【図１４Ａ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩＩを処理するのかを説明する。
【図１４Ｂ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩＩを処理するのかを説明する。
【図１４Ｃ】ＲＦＣ  ３７２５に説明されるように、ＳＩＰ  ＰＭがどのようにして３ｐｃｃ呼の流れＩＩＩを処理するのかを説明する。
【図１】
2008541301.tif 000003
【図２】
2008541301.tif 000004
【図３】
2008541301.tif 000005
【図４Ａ】
2008541301.tif 000006
【図４Ｂ】
2008541301.tif 000007
【図５】
2008541301.tif 000008
【図６】
2008541301.tif 000009
【図７】
2008541301.tif 000010
【図８】
2008541301.tif 000011
【図９】
2008541301.tif 000012
【図１０】
2008541301.tif 000013
【図１１Ａ】
2008541301.tif 000014
【図１１Ｂ】
2008541301.tif 000015
【図１１Ｃ】
2008541301.tif 000016
【図１１Ｄ】
2008541301.tif 000017
【図１２Ａ】
2008541301.tif 000018
【図１２Ｂ】
2008541301.tif 000019
【図１３Ａ】
2008541301.tif 000020
【図１３Ｂ】
2008541301.tif 000021
【図１４Ａ】
2008541301.tif 000022
【図１４Ｂ】
2008541301.tif 000023
【図１４Ｃ】
2008541301.tif 000024
【国際調査報告】
2008541301.tif 000025