(57)【要約】【課題】メディア・ストリームのためのトレースルートおよびタイミング情報を提供するための方法および装置を提供する。【解決手段】  ネットワークを介するメディア・パケットについての経路およびタイミング情報を得るための装置は、メディア・パケットのうちの再伝送される１つのパケットがネットワーク・エンドポイントによって返されるまで、後続する各パケットがホップ指定フィールドにより大きな値を挿入された前記メディア・パケットのうちのいくつかのパケットを送信し、パケットを返すネットワーク・ノードにより、所定の数に前記指定ホップ数が減分されたために送信されたメディア・パケットのいくつかを返す各ネットワーク・ノードのＩＤを記録し、再伝送されたメディア・パケットのラウンド・トリップの時間量を計算し、記録されたネットワーク・ノードＩＤから経路を決定する。【選択図】図１
2005318606.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してメディア・パケットについての経路およびタイミング情報を得るための方法であって、
１組のメディア・パケットのうちの１つのパケットに、所定の数に等しい指定ホップ数を挿入する工程と、
前記１組のメディア・パケットのうちの前記１つのパケットを、第１のネットワーク・エンドポイントによって、ネットワーク・ノードを含むネットワークを介して、第２のネットワーク・エンドポイントに送信する工程と、
前記第１および第２のネットワーク・エンドポイントの間のネットワーク経路にある前記ｎ個目のネットワークによって返される非メディア・パケット上に前記ｎ個目のネットワーク・ノードのＩＤを記録する工程であって、ｎは、前記１組のメディア・パケットうち前記１つのパケット内の前記指定ホップ数に等しく、それにより、前記ｎ個目のネットワーク・ノードが前記非メディア・パケットを返すようになる工程と、
前記第１のネットワーク・エンドポイントにより、前記１組のメディア・パケットのうちの新しい１つのパケットに対する前記指定ホップ数を増分し、前記ｎ個目のネットワーク・ノードによって前記非メディア・パケットが返されたとき前記送信する工程を繰り返す工程と、
前記第２のネットワーク・エンドポイントによって、前記１組のメディア・パケットのうちの受信された１つを前記第１のネットワーク・エンドポイントに再伝送する工程と、
前記第１および第２のネットワーク・エンドポイント間で前記１組のメディア・パケットのうちの受け取られ再伝送された１つのパケットのラウンド・トリップの時間量を、前記第１のネットワーク・エンドポイントによって計算し、前記記録されたネットワーク・ノードＩＤから経路を決定する工程とを含む方法。
【請求項２】
拡張ヘッダ・フィールドに一意の情報を挿入することにより、前記１組のメディア・パケットを他のメディア・パケットから区別する工程をさらに含む、請求項１に記載の方法。
【請求項３】
前記メディア・パケットがＲＴＰパケットであり、前記区別する工程は、ＲＴＰパケットの各組に拡張フィールドを作成する工程を含む、請求項２に記載の方法。
【請求項４】
コード・フィールドに一意の情報を挿入することにより、前記１組のメディア・パケットを他のメディア・パケットから区別する工程をさらに含む、請求項１に記載の方法。
【請求項５】
前記記録する工程がさらに、前記１組のメディア・パケットのうちの前記１つのパケットの送信と、前記ｎ個目のネットワーク・ノードによって返された前記非メディア・パケットの受信との間の時間量を、前記第１のネットワーク・エンドポイントによって決定する、請求項１に記載の方法。
【請求項６】
前記送信する工程が、前記１組のメディア・パケットのうちの前記１つのパケットに、タイム・スタンプを挿入する工程を含む、請求項１に記載の方法。
【請求項７】
ネットワークを介するメディア・パケットについての経路およびタイミング情報を得るための装置であって、
メディア・パケットのうちの再伝送される１つのパケットがネットワーク・エンドポイントによって返されるまで、後続する各パケットがホップ指定フィールドにより大きな値を挿入された前記メディア・パケットのうちのいくつかのパケットを送信する手段と、
前記パケットを返すネットワーク・ノードにより、所定の数に前記指定ホップ数が減分されたために前記送信されたメディア・パケットのいくつかを返す各ネットワーク・ノードのＩＤを記録する手段と、
前記再伝送されたメディア・パケットのラウンド・トリップの時間量を計算し、前記記録されたネットワーク・ノードＩＤから経路を決定する手段とを含む装置。
【請求項８】
前記送信するための手段が、送信される各メディア・パケットにタイム・スタンプを挿入する手段を含む、請求項７に記載の装置。
【請求項９】
前記再伝送されるメディア・パケットは、その受信から再伝送までの処理時間をそのパケット内に挿入される、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関し、詳細には、メディア・ストリームの伝送に利用されるネットワーク要素の監視に関する。
【背景技術】
【０００２】
従来技術では、ＶｏＩＰ（ボイス・オーバＩＰ）などマルチメディアの伝送を行うパケット・ネットワークのトラブル・シューティングおよび監視において周知の問題は、２つのネットワーク装置間の経路を追跡すること、および音声／メディア・パケットが経験するラウンド・トリップ・タイム（ＲＴＴ）を決定することである。（通常、トレースルートと呼ばれる）経路の決定に関して、従来技術では、トレースルートの実施においてＩＣＭＰパケットまたはＵＤＰ（ユーザ・ダイアグラム・プロトコル）パケットを利用することが知られている。実際のメディア情報はＲＴＰパケットによって移送されているため、従来技術においてＩＣＭＰパケットおよびＵＤＰパケットが使用されるとき、２つのネットワーク装置間で利用されているＩＰプロトコルまたはソース、および宛先ポート（ｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ）は、実際にＲＴＰパケットが利用するものとは異なるものになる。異なるＵＤＰソースおよび宛先ポート番号を使用する理由は、パケットが最終的に宛先に到着したときポート番号が認識されないためにパケットが拒否されるからである。さらに、いくつかの理由で、ＩＣＭＰパケットおよびＵＤＰパケットは、ＲＴＰパケットと同じネットワーク経路に従わず、つまりＲＴＰパケットと同じサービス品質（ＱｏＳ）の処置が与えられないことがある。第１に、ＲＳＶＰ予約を利用して、ネットワークを介した経路をＲＴＰトラフィックのためにセットアップするが、ＩＣＭＰおよびＵＤＰパケットは、ＲＳＶＰ予約を利用してセットアップされた経路に必ずしも従わない。第２に、ファイアウォールおよびゲートウェイが、ＲＴＰパケットと見なされないＵＤＰトラフィックを遮断するおそれがあることは従来技術では周知のことである。第３に、ファイアウォールおよびゲートウェイが、期待されるＲＴＰパケットと同じサイズではないトラフィックを廃棄することも従来技術では周知のことである。第４に、ＶｏＩＰ装置（特に高いポート密度の装置）は、ＤｏＳ攻撃を回避するために、標準ＩＣＭＰ宛先到達不能パケットで、ＵＤＰトラフィックおよび／またはＩＣＭＰエコーのすべてに対しては応答しないことも望ましい。ＵＤＰパケットおよび／またはＩＣＭＰエコーに対して返されたＩＣＭＰ宛先到達不能パケットは、経路情報を得るために使用されるので、ネットワークを介した経路を決定するために必要である。上記４つの理由により、このような問題は、媒体を搬送するＲＴＰパケットがたどる経路と比べて異なったＩＰ経路に従うトレースルート・パケットに帰結することができる。また、当技術分野で周知のように、ファイアウォールおよびゲートウェイ・フィルタリングのため、ネットワークを介したＩＣＭＰパケットまたはＵＤＰパケットの経路が存在し得ないこともある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
これに関係する問題が、ＲＴＴを使用したリアルタイム・コントロール・プロトコル（ＲＴＣＰ）パケットの決定において存在する。異なるＵＤＰソースおよび宛先ポートを使用してＲＴＣＰパケットを送信するため、ＲＴＣＰパケットが、ネットワークによって異なる処理を受けることはよくあることである。ネットワーク装置間のＲＴＴの決定に使用されるときにＲＴＣＰパケットに対し追加される要件では、パケットは、ＲＴＰパケットに提供されるのものと同様の処理をネットワークから受けるために有効な形で、ＲＴＰパケットと同じＤＳＣＰ（Ｄｉｆｆｅｒｖ（ディフサーブ）コード・ポイント）によってマーク付けされなければならない。ただし、ＲＴＰパケットに使用するのと同じＤＳＣＰをＲＴＣＰパケットに対して利用することにより、以下の問題のすべてが解決されるわけではない。第１に、ＲＴＣＰパケットはサイズが様々で一般的にはＲＴＰパケットより大きく、このことがネットワークによるパケットの処理に影響する。第２に、ＲＴＣＰパケットは、ＲＴＰパケットが送られる速度の５００分の１ほどの低速度で送られ、これもまた、ネットワークによるパケットの処理に影響する。第３に、パケットのＲＴＰストリームを保護するために行われるＲＳＶＰ予約が、ＲＴＣＰストリームの保護のために行われることはめったになく、ＲＳＶＰパケットをＲＴＣＰパケット向けに作成した場合、トラフィック・プロファイルが大幅に異なるため、このパケットは、失敗しかつ／または異なる処理を受けることがあり得る。要約すると、ＲＴＣＰパケットを用いて計算したＲＴＴの結果は、実際のメディアを搬送するＲＴＰパケットが経験する実際のＲＴＴとは異なることがある。
【課題を解決するための手段】
【０００４】
トレースルートおよびラウンド・トリップ・タイム情報を決定するために特別に定義されたプロファイルを有するＲＴＰパケットを使用する装置および方法により、上記の問題が解決され、当技術分野における技術進歩が達成される。
【発明を実施するための最良の形態】
【０００５】
本発明の実施形態により、トレースルートおよびラウンド・トリップ・タイム（ＲＴＴ）情報を得るために特に使用されるパケット用の新しいＲＴＰプロファイルが定義される。有利なことに、従来の手法ではなく新しいＲＴＰトレースルート・パケットの使用においては、メディア・ストリームを構成するＲＴＰパケットとまったく同じ特性をＲＴＰトレースルート・パケットが有している。これが下記の利点を有することは、当業者には容易に想像されよう。第１に、ＲＴＰトレースルート・パケットは、メディアを搬送するＲＴＰパケットと同じＵＤＰソースおよび宛先ポートを使用する。これにより、ファイアウォールおよびゲートウェイに関連する問題が解消され、単一のＲＳＶＰ予約でストリームを保護することが可能になり、したがって、ネットワークによるＲＴＰトレースルート・パケットの処理がＲＴＰメディア・パケットと同じ処理であることが保証される。第２に、ＲＴＣＰパケットは、ＲＴＴ情報を決定するために利用されないので、メディアの優先順位ではなく信号方式優先順位のＤＳＣＰを用いてマーク付けすることができる。というのは、この場合、ＲＴＣＰパケットは、ＲＴＴを計算するのに利用されるのではなく、単純に、メディアＲＴＰパケットの受信に関する情報を信号でネットワーク装置に送るからである。
【０００６】
図１は、ネットワーク１０３を介してＶｏＩＰ（ボイス・オーバＩＰ）装置１０２に送信を行うＶｏＩＰ装置を例示する本発明の実施形態を示している。これから述べる様々な実施形態をＶｏＩＰ装置以外の装置が利用することもでき、一般的に、ＲＴＰプロトコルを利用する任意の装置にこの方式が適用されることは、当業者には直ちに理解されよう。ネットワーク１０３は、ルータ１０４乃至１０８からなる。ルータ１０４乃至１０７は、ＶｏＩＰ装置１０１およびＶｏＩＰ装置１０２を相互接続する経路を形成する。ネットワーク１０３を介した経路および時間遅延を決定するために、装置１０１は、図２で実施形態として示すＲＴＰ要求トレースルート・フォーマットを有するパケットであるＲＴＰトレースルート・パケットを送信する。この実装形態では、拡張フィールド２０９が設定され、拡張ヘッダ・フィールド２０３は、このパケットがＲＴＰトレースルート・パケットであることを定義する情報を含む。装置１０１から装置１０２への経路がルータ１０４乃至１０７を経由するか判定するために、図６に示すように、装置１０１が、ＲＴＰトレースルート・パケットを送信する。
【０００７】
この方法は、経路が従来のトレースルート形式のプログラムで使用される方法と同様であるかを判定するために使用される。この判定には、インターネット・プロトコル（ＩＰ）有効期間（ＴＴＬ）フィールドを増大する値に設定することが利用される。各ルータのアドレスは、ＩＣＭＰのＴＴＬ期限切れの応答によって決定される。まず、装置１０１は、ホップ数（ＴＴＬ＝１、フィールド２１２）を有し１ホップに設定されたＲＴＰトレースルート・パケット、パケット６０１を送信する。ルータ１０４は、装置１０２には１ホップのみで到達することができないことから、パケット６０１に応答して、装置１０１にＩＣＭＰ（ＴＴＬ期限切れ）パケット６０２を返す。また、ＩＣＭＰパケットには、ルータ１０４がこのパケットを送信したことが定義される。本発明の他の実施形態では、事前に定義された数のＲＴＰトレースレート・パケットが、装置１０１によってＴＴＬ＝１で送信されるが、これらのパケットは異なるペイロードを有し、それによってチェックサムがパケットごとに異なるようにする。装置１０１は、チェックサムの差異を使用して、返されたトレースルート・パケットのシーケンスを決定する。返されたトレースルート・パケットのシーケンスが分かることにより、装置１０１は、返された各パケットのルータ１０４を介したラウンド・トリップ遅延を決定することができる。
【０００８】
次に、装置１０１が、ＴＴＬフィールド２１２が２に等しく設定された第２のＲＴＰトレースルート・パケットを送信する。このパケットは、ルータ１０４によってルータ１０６に送られ、ルータ１０６は、装置１０２には２ホップだけでは到達できないことを決定し、ＩＣＭＰパケット６０４を装置１０１に送信して返し、パケット６０４には、ルータ１０６がこのパケットを送信したことが定義される。本発明の他の実施形態では、事前に定義された数のＲＴＰトレースルート・パケットが、装置１０１によってＴＴＬ＝２で送信されるが、これらのパケットは異なるペイロードを有し、それによってこれらのパケットごとにチェックサムが異なるようにする。装置１０１は、チェックサムの差異を使用して、返されたトレースルート・パケットのシーケンスを決定する。返されたトレースルート・パケットのシーケンスが分かることにより、装置１０１は、返された各パケットのルータ１０６を介したラウンド・トリップ遅延を決定することができる。
【０００９】
次に、装置１０１は、ＴＴＬフィールド２１２が３に等しく設定されたパケット６０６を送信する。このパケットは、ルータ１０４および１０６を介してルータ１０７に到達する。ルータ１０７は、パケットがルータ１０７に到達したが装置１０２には到達できないことが装置１０１に定義されたＩＣＭＰパケット（ＴＴＬ期限切れの）パケット６０７を装置１０１に返す。本発明の他の実施形態では、事前に定義された数のＲＴＰトレースルート・パケットが、装置１０１によってＴＴＬ＝３で送信されるが、これらのパケットは異なるペイロードを有し、それによってパケットごとにチェックサムが異なるようにする。装置１０１は、チェックサムの差異を使用して、返されたトレースルート・パケットのシーケンスを決定する。返されたトレースルート・パケットのシーケンスが分かることにより、装置１０１は、返された各パケットのルータ１０７を介したラウンド・トリップ遅延を決定することができる。
【００１０】
最後に、装置１０１は、４に等しく設定されたＴＴＬフィールド２１２を有するＲＴＰ要求トレースルート・パケット６０８を送信し、このパケットは装置１０２に到達し、装置１０２は、ＲＴＰ応答トレースルート・パケットすなわち図３に示すパケット６０９によって応答する。図３のＲＴＰ応答トレースルート・パケットは、図２のパケットと区別するために拡張ヘッダ・フィールド３０２内に異なる内容を有する。装置１０２は、受信したＲＴＰ要求トレースルート・パケットのＮＴＰタイム・スタンプ・ワード２０４および２０６を、ワード３０３および３０４（最終ＲＴＴ要求タイム・スタンプ）に挿入し、装置１０２によるＲＴＰ要求トレースルート・パケットの受信とＲＴＰ応答トレースルート・パケット６０９の送信の間の遅延をワード３０６および３０７に挿入する。装置１０１に送信してパケット６０９を返す前に、パッド・ワード３０８から３０９が、所望の長さ、たとえばメディア・ストリームにおけるＲＴＰパケットと同じ長さまで埋められる。
【００１１】
装置１０１は、パケット６０９の受信に応じて装置１０１と装置１０２の間でのラウンド・トリップ伝送時間を決定する。パケット６０２、６０４、６０７からの情報によっても経路が決定される。パケット６０２、６０４、６０７のタイミング情報もまた、経路にある別個の各ルータに対するラウンド・トリップ・タイムを決定するために使用することができる。
【００１２】
図４および５は、図２および３の拡張ヘッダ・フィールドを使用せずＰＴフィールド４１１および５１１でパケットを要求トレースルート・パケットおよび応答トレースルート・パケットとして定義するという点で、図２および３の実施形態とは異なる他の実施形態を示す。図４および５には拡張ヘッダ・フィールドがないことに留意されたい。図４のフィールド４０１および４０４乃至４１３は、機能において、図２のフィールド２０１および２０４乃至２１３と同様である。図５のフィールド５０１および５０３乃至５０９は、図３のフィールド３０１および３０３乃至３０９と機能において同様である。
【００１３】
図７乃至９は、ＶｏＩＰ装置１０１または１０２などのエンドポイント装置の動作の実装において本発明の様々な実施形態で実行される動作をフローチャートの形で示す。図７乃至９に示す動作を実行するために、ＶｏＩＰ装置以外の装置を利用することができることは当業者には直ちに理解されよう。図７乃至９は、本発明の実施形態の実施において、エンドポイント装置によって実行される動作を、テスト動作を実行するエンドポイント装置と、テスト・パケット（ＲＴＰ要求パケット）に応答するエンドポイント装置でまたＲＴＰ応答パケットによって応答するエンドポイント装置との両側から示す。ブロック７０１から開始後、判断ブロック７０２では、音声／メディア・パケットが経験するラウンド・トリップ・タイム、およびこれらのパケットが移送される経路を検査する時であるかどうかを判定する。現在セットアップされたメディア呼出しがない場合、判断ブロック７０２は実施されないことに留意されたい。判断ブロック７０２で回答が、いいえの場合、制御が図９の判断ブロック９０１に進む。
【００１４】
判断ブロック７０２で回答が、はいの場合、ブロック７０４でホップ数（ＴＴＬ）を１に等しく設定し、１に等しく設定されたＴＴＬを有するが各パケットが異なるチェックサムを有する一連のトレースルートＲＴＰ要求パケットを送信する。これらのパケットに異なる量のデータを埋め込むことによって異なるチェックサムが達成される。ブロック７１１で記述されているように、経路上のルータからパケットが返された後も、チェックサムは、引き続きパケットのシーケンスを決定するために利用される。判断ブロック７０７の実施前に一連のパケット全部が送信されることが示されているが、他の実施形態では、一連のＲＴＰ要求パケットの送信を、ブロック７０７乃至７１６の範囲に散在させることができることに留意されたい。さらに別の実施形態では、１つのＲＴＰ要求パケットだけがブロック７０６で送信される。
【００１５】
判断ブロック７０７で、ホップ数が図１の装置１０２など宛先の装置に到達するのに不十分なために、パケットがルータまたは他のネットワーク要素から返されたかどうかを判定する。このようなパケットは、ＩＣＭＰ（ＴＴＬ期限切れ）パケットである。ＴＴＬフィールドに指定されたホップ数が宛先の装置に到達するのに不十分な場合、ルータ１０４などのネットワーク要素がこのようなパケットを返す。判断ブロック７０７で回答が、はいの場合、制御は判断ブロック７０８に進む。次の判断ブロックでは、ブロック７０６で送信されたパケットすべてが受信されたかどうかを判定する。ブロック７０８ではまた、これらのパケットの一部が送信の間に逸失し得ることを考慮して必要なタイムアウト動作を実施する。判定ブロック７０８で回答が、いいえの場合、制御は判断ブロック７０７に戻る。判断ブロック７０８で回答が、はいの場合、ブロック７０９で、異なる検査符合を利用して、返されたＩＣＭＰパケットをソートし、ブロック７１１では、ＲＴＴおよび経路情報を後で使用するために格納する。最後に、ブロック７１２で、制御がブロック７０６に戻る前に、ＴＴＬを増分し、それによって別の一連のＲＴＰ要求パケットを送信することができるようにする。
【００１６】
判断ブロック７０７に戻り参照すると、判断ブロック７０７で回答が、いいえの場合、判断ブロック７１３に制御は進み、ＲＴＰ応答パケットが宛先の装置から受け取られたかどうかを判定する。回答がはいの場合、ブロック８０１に制御は進み、応答パケットが含む情報に基づいてＲＴＴを計算する。ＲＴＰ応答パケットは、図３および５に示すフォーマットを有する。本発明の一実施形態では、複数のＲＴＰ要求パケットが送信され、ブロック８０１の動作により、その結果もたらされたＲＴＰ応答パケットから算出されたＲＴＴ情報を平均する。判断ブロック８０２で、ＲＴＴ情報が過大であるかどうかを判定する。この回答がはいの場合、ブロック８０３で修正措置が行われる。この修正措置は、新しい経路をセットアップする、またはネットワーク内に存在する問題を他のエンティティに通知する管理プロセスを単に実行する試みとすることができる。一実施形態では、図７のブロック７１１で収集される情報が、ブロック８０３の修正措置で使用される。ブロック８０３の実施後、または判断ブロック８０２における回答がいいえの場合、制御は図７の判断ブロック７０２に戻る。
【００１７】
図７の判断ブロック７１３に戻り参照すると、判断ブロック７１３で回答が、いいえの場合、判断ブロック７１４で、ＲＴＰ要求パケットが受信されたかどうか判定する。判断ブロック７１４の機能は、ネットワーク・エンドポイントが、ＲＴＰ要求パケットを送信する他のネットワーク・エンドポイントの宛先ポイントである場合に動作を実施することである。判断ブロック７１４の情報が、はいの場合、図８のブロック８０４に制御は進み、ブロック８０４では、受信側エンドポイントにおける遅延を計算し、ブロック８０６で、ＲＴＰ応答パケットを形成し、そのパケットを送信側エンドポイントに送信して返し、その後、図７の判断ブロック７０７に制御が戻る。
【００１８】
判断ブロック７０２に戻り参照すると、ブロック７０２で回答が、いいえの場合、制御は図９の判断ブロック９０１に進む。判断ブロック９０１で、ＲＴＰ要求パケットが受信されたかどうかを判定する。この回答がいいえの場合、ブロック９０４に制御は進み、ここで通常の処理を行い、その後、図７の判断ブロック７０２に制御が戻る。判断ブロック９０１で回答が、はいの場合、ブロック９０２で、受信側のブロックの範囲内の遅延を計算し、ブロック９０３で、図８のブロック８０４および８０６に関して先に説明したのと同様にＲＴＴ応答パケットを形成し送信する。
【００１９】
図１０は、ＶｏＩＰ装置１１２などのＶｏＩＰ装置の一実施形態を示すブロック図である。プロセッサ１００２は、プログラムを実行し、メモリ１００１にデータを格納しそれからデータを取り出すことによりＶｏＩＰ装置１１２の機能に対する全般的な制御を行う。プロセッサ１００２は、インターフェース１００３を介してネットワーク１０３に接続される。プロセッサ１００２は、インターフェース１００７を介して送受話器１０１８とインターフェースをとり、インターフェース１００９を介して視覚表示装置およびボタン１０１９に接続される。視覚表示装置およびボタン１０１９は、ＶｏＩＰ装置のためのすべてのインジケータ、ボタン・キーパッド、およびディスプレイである。プロセッサ１００２は、メモリ１００１内に例示するルーチンを実行することにより、ＶｏＩＰ装置１１２の動作を実施する。
【００２０】
オペレーティング・システム１０１２は、全般的な制御、および必要なプロトコル動作を行う。データは、データ・ブロック１０１３に格納される。コーデック１０１４は、ネットワーク１０３と通信するための送受話器１０１８、または会議用スピーカおよびマイク１００６と通信するために、音声情報のエンコードおよびデコードを行う。呼出し処理の全般的な制御は、呼出し処理ルーチン１０１６の制御下でＶｏＩＰ装置１１２により行われる。図１０に示す様々なインターフェースに関する通信および制御は、インターフェース・ルーチン１０１７によって行われる。ルーチンおよびタイミング・アプリケーション１００８は、図７乃至９に示す動作を制御する。
【００２１】
ＶｏＩＰ装置の動作がソフトウェアで実装されるとき、このソフトウェアは、任意のコンピュータに関係するシステムまたは方法によって使用されるまたは関連して使用される、どのようなコンピュータ可読媒体にも格納することができることに留意されたい。この文書の文脈で、コンピュータ可読媒体は、コンピュータに関係するシステムまたは方法によって使用されるまたは関連して使用されるコンピュータ・プログラムを含むまたは格納することができる、電子式、磁気式、光学式または他の物理的な装置または手段である。ＶｏＩＰ装置は、命令実行システム、機器、または装置から命令を取り出し実行することができる、コンピュータ・ベースのシステム、プロセッサを含むシステム、または他のシステムなどの、命令実行システム、機器、または装置によって使用されるまたは関連して使用される任意のコンピュータ可読媒体で実施することができる。この文書の文脈では、「コンピュータ可読媒体」は、命令実行システム、機器、または装置によって使用するまたは関連して使用するプログラムの格納、通信、伝播、または移送を行う任意の手段とすることができる。コンピュータ可読媒体は、それだけに限らないが、たとえば、電子、磁気、光、電磁気、赤外線、または半導体の、システム、機器、装置、または伝播媒体とすることができる。コンピュータ可読媒体のより具体的な例（網羅的ではないリスト）には、１つまたは複数の電線を用いた電気的接続（電子）、ポータブル・コンピュータ・ディスケット（磁気）、ＲＡＭ（ランダム・アクセス・メモリ）（電子）、ＲＯＭ（読取り専用メモリ）（電子）、消去可能プログラマブルＲＯＭ（ＥＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュメモリ）（電子）、光ファイバ（光）、および、ポータブルＣＤＲＯＭ（コンパクト・ディスクＲＯＭ）（光）が含まれる。プログラムは、たとえば紙または他の媒体を光学的に走査することによって電子的に取り込み、次いで、コンパイル、インタープリット、または必要なら他の適切な方式の処理を行い、その後、コンピュータ・メモリに格納することができるため、コンピュータ可読媒体は、プログラムが印刷される紙または他の適切な媒体とすることもできることに留意されたい。
【００２２】
ＶｏＩＰ装置がハードウェアで実装される代替実施形態では、ＶｏＩＰ装置は、それぞれ当技術分野で周知の技術である、データ信号上の論理関数を実装する論理ゲートを有するディスクリート論理回路、適切な組合せ論理ゲートを有するＡＳＩＣ（特定用途向け集積回路）、ＰＧＡ（プログラマブル・ゲート・アレイ）、および、ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）などの任意の技術または組合せによって実装することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態を示す図である。
【図２】本発明の実施形態で利用されるパケットのフォーマットを示す図である。
【図３】本発明の実施形態で利用されるパケットのフォーマットを示す図である。
【図４】本発明の実施形態で利用されるパケットのフォーマットを示す図である。
【図５】本発明の実施形態で利用されるパケットのフォーマットを示す図である。
【図６】図１のネットワークを介してパケットを送信する順序を示す図である。
【図７】本発明の実施形態による、送信または受信を行うネットワーク・エンドポイントによって実施される動作を示すフローチャートである。
【図８】本発明の実施形態による、送信または受信を行うネットワーク・エンドポイントによって実施される動作を示すフローチャートである。
【図９】本発明の実施形態による、送信または受信を行うネットワーク・エンドポイントによって実施される動作を示すフローチャートである。
【図１０】ＩＰ電話機の実施形態を示すブロック図である。
【図１】
2005318606.tif 000003
【図２】
2005318606.tif 000004
【図３】
2005318606.tif 000005
【図４】
2005318606.tif 000006
【図５】
2005318606.tif 000007
【図６】
2005318606.tif 000008
【図７】
2005318606.tif 000009
【図８】
2005318606.tif 000010
【図９】
2005318606.tif 000011
【図１０】
2005318606.tif 000012