インターネットを介してＦＡＸデータを通信する方法及び機器
【課題】パケット交換ネットワークを介してファックス関連データを伝送するファックス伝送方法を提供する。
【解決手段】方法は、第１ストリーミング・プロトコルを使用してファックス・データセットをカプセル化し、第２ストリーミング・プロトコルを使用してファックス・パケットを更にカプセル化することを含む。この方法はまた、パケットを受信すること、第２ストリーミング・プロトコルを使用することによってパケットをカプセル化解除し、ファックス・パケットを得ること、及び第２ストリーミング・プロトコルを使用してファックス・パケットをカプセル化解除し、ファックス・データセットを得ることを含むことができる。このファックス伝送方法を使用する、パケット交換ネットワークを介してファックス関連データを送信する機器も提供される。
【解決手段】方法は、第１ストリーミング・プロトコルを使用してファックス・データセットをカプセル化し、第２ストリーミング・プロトコルを使用してファックス・パケットを更にカプセル化することを含む。この方法はまた、パケットを受信すること、第２ストリーミング・プロトコルを使用することによってパケットをカプセル化解除し、ファックス・パケットを得ること、及び第２ストリーミング・プロトコルを使用してファックス・パケットをカプセル化解除し、ファックス・データセットを得ることを含むことができる。このファックス伝送方法を使用する、パケット交換ネットワークを介してファックス関連データを送信する機器も提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に、通信システムの分野に関する。より詳細には、本開示は、インターネットを介してファクシミリ・データを通信する方法及び機器に関する。
【背景技術】
【０００２】
広域ネットワーク（ＷＡＮ）は、ローカル・エリア・ネットワーク（ＬＡＮ）を互いに接続するのに使用され、それによって、ある場所のユーザ及びコンピュータが、他の場所のユーザ及びコンピュータと通信することができる。インターネットや類似のインターネット・プロトコル（「ＩＰ」）ベースのネットワーク（以後、より一般的に「ＩＰネットワーク」と呼ぶ）などの進行中のＷＡＮの開発／普及のおかげで、一層多くの人々が、ＩＰネットワークを使用して、音声及びファックス呼を含む、データ、ビデオ、オーディオなどの様々なタイプの情報を交換している（本明細書では、音声及びファックス呼とは、上述のタイプの情報のうちの任意の１つ又は複数に対応する信号を送信又は受信することを可能にし、或いは実際に送信又は受信する任意の呼接続と定義され、本明細書では、そのすべてをより一般的に「ファックス呼」と呼ぶ）。２つの適切なマシン（本明細書では「ファックス」とも呼ぶこともある）間のＩＰネットワークを介するファックス呼の通信は一般に、ゲートウェイを介するファックス・トーン及びファックス・データの送信及び受信が関係するので、そのようなゲートウェイは、インターネット・プロトコルを介するファックス（「ＦｏＩＰ」）と、インターネット・プロトコル（「ＶｏＩＰ」）を介する音声などの他の情報とをどちらも処理するように適合される。従って、ゲートウェイは一般に、そのようなファックス呼を可能にするファックス中継と、口頭通信及びモデム通信を可能にするスピーチ・コーダ及び音声帯域データ（「ＶＤＢ」）経路とを含む。
【０００３】
通信ネットワークでは、「ゲートウェイ」（プロトコル変換器とも呼ばれる）という用語は一般に、異なるプロトコルを使用する別のネットワークとインターフェースするように装備されたネットワーク・ノードを指す。ゲートウェイは一般に、ローカル・エリア・ネットワーク（「ＬＡＮ」）とＷＡＮとの間の共通交点に配置され、システム相互運用性を実現するために、必要に応じてプロトコル変換器、インピーダンス整合装置、レート変換器、障害分離器、信号変換器を含むことができる。プロトコル変換／マッピング・ゲートウェイは、必要なプロトコル変換を実施することにより、異なるネットワーク・プロトコル技術を用いたネットワークを相互接続する。ルータは、ゲートウェイの特殊ケースである。ゲートウェイについての詳細は、「Ａｃｃｅｓｓ Ｇａｔｅｗａｙ」（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｓｏｒｔｉｕｍ、２００５年）から得ることができる。
【０００４】
ファックス及び音声通信に関する特徴及び要件が異なるので、２つの異なるタイプのパケット・ストリームは一般に、２つの異なる動作モードで別個に使用される。第１のタイプのパケット・ストリームは、ＶｏＩＰ通信で使用され、リアル・タイム転送プロトコル（「ＲＴＰ」）パケット・ストリームと呼ばれる。Ａｕｄｉｏ Ｖｉｄｅｏ Ｔｒａｎｓｐｏｒｔ（「ＡＶＴ」） Ｉｎｔｅｒｎｅｔフォーラムと呼ばれる国際フォーラムが、異なるメディア・タイプ及び目的のために、幾つかのＲｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ（「ＲＦＣ」）仕様でＲＴＰプロトコルを定義した。例えば、ＶｏＩＰに関する一般的なＲＦＣは、ＲＦＣ ３５５０（「Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ」）であり、これが、ＲＦＣ １８８９、ＲＦＣ ２１９８（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｕｄｉｏ Ｄａｔａ」）、ＲＦＣ ２７３３（「Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ」）、及びＲＦＣ ２８３３（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ ＤＴＭＦ Ｄｉｇｉｔｓ， Ｔｅｌｅｐｈｏｎｙ Ｔｏｎｅｓ ａｎｄ Ｔｅｌｅｐｈｏｎｙ Ｓｉｇｎａｌｓ」）に取って代わった。
【０００５】
ＲＴＰ経路を介して転送される典型的な信号は、音声信号、デュアル・トーン・マルチフリーケンシ（「ＤＴＭＦ」）信号、回線個別信号方式（「ＣＡＳ」）、ＲＦＣ ２８３３仕様に従って中継され、又は音声帯域データ（「ＶＢＤ」）モードで転送されるモデム信号、ビデオ信号などである。ＲＴＰ及びＲＴＰ関連データを処理するのに使用することのできるＲＴＰ経路は、パケット損失のストリームの暗号化及び／又は保護を容易にする手順と、パケット・リオーダと、その他の手順の使用を含むことができる。異なるタイプのＲＴＰストリーム（例えば、通常の音声、ＤＴＭＦ、ＶＢＤ、ビデオ・データ）間の切換えは、ＲＴＰヘッダ内で転送される（ＲＴＰヘッダ内にカプセル化される）ペイロード・タイプを（固有ストリーム識別子として）使用することによってリアル・タイムに実施される。通常、異なるタイプＲＴＰストリーム間で切り換えることは、通信セッションに関係するゲートウェイ間のリアル・タイム・ネゴシエーションを必要としない。
【０００６】
ファックス・データを通信するために、ＲＴＰ経路をそのまま（適合なしで）使用することを試みることは一般に、通信に関係する装置（例えばゲートウェイ及びファックス・マシン）の信頼性及び相互運用性を著しく低下させる。従って、ＦｏＩＰ通信では、当業者には「Ｔ．３８パケット・ストリーム」として知られる異なるタイプのパケット・ストリームが使用される。Ｔ．３８経路パケット・ストリームはＴ．３８経路で処理される。「Ｔ．３８経路」という用語は一般に、ファックス中継データ・ストリーム（Ｔ．３８パケット・ストリーム）の処理（符号化、復号化、回復など）に関係するゲートウェイ及び関連する処理ルーチンと共に配置することができ、又はそれらと関連付けることのできる電子回路を指す。Ｔ．３８データ・パケットは、Ｔ．３８ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎに従ってフォーマットされ、ＴＣＰ又はＵＤＰＴＬを使用してＩＰネットワークを介して中継される。ファックス信号の大きな遅延を導入するＴ．３８／ＴＣＰプロトコルはまれにしか使用されず、従って、以後このタイプのプロトコルは参照しない。Ｔ．３８／ＵＤＰＴＬトランスポートは、パケット損失のストリームの保護、並びに通信ゲートウェイがＴ．３８ストリーム誤りを個々に補正することを可能にするパケット・リオーダを容易にする手順を含む。これらの手順は、ＵＤＰＴＬシーケンス番号及び誤り保護方式の使用を含む。Ｔ．３８ ＵＤＰＴＬで使用される典型的な誤り回復方法は、「２次パケット」を使用する冗長性機能の使用を含む。別のＵＤＰＴＬ誤り回復方式は、パリティ前方誤り訂正（「ＦＥＣ」）を使用する。最後に述べた２つの手順又は方式は、Ｔ．３８ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎにより完全に説明されている。
【０００７】
各タイプのパケット・ストリームは、以下でより完全に説明するように利点と欠点を有する。例えば、Ｔ．３８／ＵＤＰＴＬプロトコルは、長らくファックス中継で広く使用されている周知のプロトコルであり、異なるベンダのゲートウェイ及びファックス・マシンが高い相互運用性を導入するという利点を有し、このことは、装置（ゲートウェイ、ファックス・マシンなど）のベンダの如何に関わらず、異なるゲートウェイ／ファックス・マシンなどが好都合な方式でファックス・メッセージを交換できることを意味する。更に、Ｔ．３８／ＵＤＰＴＬは、ＵＤＰＴＬパケットの複製を可能にし、ＵＤＰＴＬパケットの少なくとも１つの種類のパケットが、受信側（リモート）ゲートウェイ又は他の装置で完全な状態で受信されることが保証される。例えば、ゲートウェイはパケットの５つのコピー又は複製を生成し、それらをＩＰネットワークを介して受信側ゲートウェイに次々に転送することができ、受信側ゲートウェイは恐らく、元のパケット、又はその複製のうちの少なくとも１つを受信することになる。しかし、ＲＴＰプロトコルとは対照的に、Ｔ．３８／ＵＤＰＴＬプロトコルは暗号化を可能にせず、それにより、情報が傍受の影響を受けやすくなる可能性がある。更に、通常はファックス通信ではリアル・タイム・オーディオ応用例の場合のように重大ではないが、ＵＤＰＴＬパケットはタイム・スタンプされず、従って通信関連の統計を計算又は評価することができない。
【０００８】
ＲＴＰパケット・ストリームに関しては、伝送されるストリーム内の各ＲＴＰパケットには固有のシーケンス番号及びタイムスタンプが割り当てられ、それらを受信側ゲートウェイで使用して、パケットの統計を計算し、通信経路の品質を評価し、順序が狂って受信されたパケットを照合（リオーダ）することができる。例えば、統計計算は、ゲートウェイに到着するパケットの移動時間、遅延、ジッタなどに関係付けることができる。更に、ＲＴＰは、データの暗号化を可能にし、従って、通信されるデータのセキュリティの向上を実現する。しかし、（ゲートウェイによるのと同様に）固有シーケンス番号を各ＲＴＰパケットに割り当てることも、パケットを複製することができないという欠点を有する。
【０００９】
ＲＴＰ及びＴ．３８パケット・ストリームは一般に、互いに独立にゲートウェイによって処理される。所与の通信状態の所与のゲートウェイに関して、ＲＴＰパケット・ストリーム又はＴ．３８型パケット・ストリームをゲートウェイで処理することができるが、両方のタイプを同時に処理することはできない。別の見方をすれば、ファックス・マシンが電話（又はファックス・マシン）として動作する場合、音声（又はファックス・データ）通信に関係するゲートウェイは、それぞれ、ＲＴＰ経路（又はＴ．３８経路）を使用可能にすると同時に、Ｔ．３８経路（又はＲＴＰ経路）を使用不能にする。
【００１０】
従って、ファックス呼が音声通信／ファックス・トーン又はファックス・データの送信を含むときはいつでも、ファックス呼に関係するゲートウェイは、ある動作モード（ＲＴＰやＴ．３８など）から他の動作モード（Ｔ．３８又はＲＴＰ）に切り替わらなければならない。即ち、これらのゲートウェイは、時々、ＲＴＰ経路がＲＴＰパケット・ストリーム（呼のＶｏＩＰ部分）を処理することを可能にすると共にＴ．３８経路を使用不能にし、別の時には、Ｔ．３８／ＵＤＰＴＬ経路がＴ．３８パケット・ストリーム（呼のＦｏＩＰ部分）を処理することを可能にすると共にＲＴＰ経路を使用不能にする。「Ｔ．３８（又はＲＴＰ）経路を使用不能にする」という用語は、Ｔ．３８（又はＲＴＰ）データ・ストリームの処理に通常は関係する電子回路及び／又は（通信進行及び応用例タイプに応じて）ソフトウェア・モジュール／要素を使用不能にすることを指す。通信セッションに関係するゲートウェイがＲＴＰ動作モードとＴ．３８動作モードとの間で正しく切り替わるために、ゲートウェイは、特別なプロトコル又は補助コマンドを使用することによってリアル・タイム・ネゴシエーションを開始することができ、その特別なプロトコル又は補助コマンドを、メディア・ゲートウェイ・コントローラによってゲートウェイに転送し、例えばゲートウェイに到着しようとしている予期されるデータ・ストリームのタイプについてゲートウェイに通知することができる。ゲートウェイがＲＴＰパケット・ストリームとＴ．３８パケット・ストリームの両方を同一の宛先ポートを介して転送する場合（同時にではない）、そのようなリアル・タイム・ネゴシエーションは必須である。
【００１１】
ＲＴＰ動作モードとＴ．３８／ＵＤＰＴＬ動作モードとの間の遷移には問題がある。以下で更に説明するように、２つのゲートウェイ間のリアル・タイム・ネゴシエーションで使用される回路及びプロセスを使用可能／使用不能にすることに加えて、各動作モードで使用される異なる回路及びプロセスを適時に使用可能／使用不能にする必要があるからである。
【００１２】
ＲＴＰ（又はＴ．３８）動作モードとＴ．３８（又はＲＴＰ）動作モードの間の遷移を避けるために、Ｔ．３８機能とＲＴＰ機能を組み合わせる試みが行われている。新しく提案されたＴ．３８ベースのプロトコルによれば、Ｔ．３８／ＵＤＰＴ（又はＩＦＰ／ＵＤＰＴＬ）プロトコルとは対照的に、（Ｔ．３８ ＩＦＰパケット・ストリーム内の）Ｔ．３８ ＩＦＰ１次パケットをＲＴＰヘッダ及び任意選択のＲＴＰ冗長性又はＦＥＣと共にＲＴＰ内にカプセル化してＴ．３８／ＲＴＰ（ＩＦＰ ｏｖｅｒ ＲＴＰ、又は短縮してＩＦＰ／ＲＴＰ）プロトコルを形成すべきである。新しいプロトコル（Ｔ．３８／ＲＴＰ）は、以下で説明するようにＴ．３８／ＵＤＰＴＬに勝る幾つかの利点を有する。例えば、Ｔ．３８／ＲＴＰプロトコルは、様々なタイプのＲＴＰ媒体で共通に使用される通信標準であるセキュアＲＴＰ（「ＳＲＴＰ」）を使用することによってＲＴＰ保護されたファックス中継トランスポートを可能にする。
【００１３】
更に、新しく提案されたＴ．３８／ＲＴＰプロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルとは対照的に、２つの通信ゲートウェイ間のリアル・タイム・ネゴシエーションのための時間を費やすことなく、異なるタイプのＲＴＰペイロードを自動的に区別することによって音声（ＲＴＰを介するオーディオ）及びファックス（ＲＴＰを介するＩＦＰパケット）パケット・ストリームとの間の比較的高速な遷移を可能にする。
【００１４】
更に、ＲＴＰカプセル化は、統計評価のためにＲＴＰ制御プロトコル（「ＲＴＣＰ」）を使用することを可能にする。ＲＴＣＰは、ＲＦＣ ３５５０で定義される。ＲＴＣＰは、リアル・タイム・トランスポート制御プロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を意味し、ＲＴＰパケット・ストリームに関する帯域外制御情報を提供する。ＲＴＣＰの主な機能は、ストリーミング・マルチメディア・セッションの参加者に制御パケットを周期的に送信することにより、ＲＴＰによって提供されるサービス品質に関するフィードバックを提供することである。ＲＴＣＰは、媒体接続に関する統計と、送られたバイト、送られたパケット、失われたパケット、ジッタ、フィードバック、往復遅延などの情報とを収集する。アプリケーションは、この情報を使用して、例えばデータ・フローを制限することによって、又は高圧縮コーデックの代わりに低圧縮コーデックを使用することによってサービス品質を向上させることができる。
【００１５】
新しいＴ．３８／ＲＴＰプロトコルによれば、１次ＩＦＰパケットは、Ｔ．３８ ＵＤＰＴＬフォーマット設定を避け、その代わりに、リアル・タイム媒体データ／信号であるかのようにＲＴＰ経路を通過する。新しいＴ．３８／ＲＴＰプロトコルを実装するために、Ｔ．３８ ＵＤＰＴＬの代わりにＲＦＣ ３５５０が使用される。ファクシミリ通信の保護及び失われたパケットの回復を高め、（リオーダリング）パケットの照合を可能にするために、Ｔ．３８標準は、ＲＦＣ ２１９８で指定される任意選択の冗長性手段を使用すること、或いはＲＦＣ ２７３３で指定されるＦＥＣストリームを使用することを推奨している。ＲＦＣ ２１９８及びＲＦＣ ２７３３の内容は、参照により本明細書に組み込まれる。
【００１６】
新しいＴ．３８／ＲＴＰプロトコルも幾つかの欠点を有する。例えば、ＩＦＰ／ＲＴＰを使用する結果、Ｔ．３８／ＵＤＰＴＬと比較して、しばしば計算資源の消費が著しく増大する。部分的には、より多くの計算資源を使用する必要は、ＲＴＰプロトコルが本来はファックス・データ通信に対処するように設計されていなかったために存在する、異なるＲＴＰ及びＴ．３８／ＵＤＰＴＬ要件間の不一致を克服しようと試みる結果として生じる。更に、ＩＦＰ／ＲＴＰプロトコルで提供される相互運用性は、ファックス・データへのタイムスタンプの適用のために、ＩＦＰ／ＵＤＰＴＬプロトコルと比較して貧弱であることがある。提案されたＩＦＰ−ｏｖｅｒ−ＲＴＰ（ＩＦＰ／ＲＴＰ）プロトコルの他の欠点は、図の説明から明らかとなるであろう。
【非特許文献１】「Ａｃｃｅｓｓ Ｇａｔｅｗａｙｓ」（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｓｏｒｔｉｕｍ、２００５年）
【非特許文献２】ＲＦＣ ３５５０（「Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ」）
【非特許文献３】ＲＦＣ １８８９
【非特許文献４】ＲＦＣ ２１９８（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｕｄｉｏ Ｄａｔａ」）
【非特許文献５】ＲＦＣ ２７３３（「Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ」）
【非特許文献６】ＲＦＣ ２８３３（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ ＤＴＭＦ Ｄｉｇｉｔｓ， Ｔｅｌｅｐｈｏｎｙ Ｔｏｎｅｓ ａｎｄ Ｔｅｌｅｐｈｏｎｙ Ｓｉｇｎａｌｓ」）
【非特許文献７】ＩＴＵ−Ｔ勧告Ｔ．３８（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｒｅａｌ−ｔｉｍｅ Ｇｒｏｕｐ ３ ｆａｃｓｉｍｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｏｖｅｒ ＩＰ ｎｅｔｗｏｒｋｓ」）
【非特許文献８】Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ（「ＩＴＵ−Ｔ」）ｄｉｖｉｓｉｏｎ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｔ．３０（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｄｏｃｕｍｅｎｔ ｆａｃｓｉｍｉｌｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｉｎ ｇｅｎｅｒａｌ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋｓ」）
【非特許文献９】Ｊ．Ｒｅｙ等、「ＲＴＰ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月１５日）
【非特許文献１０】Ｊｏｈｎ Ｌａｚｚａｒｏ「Ｆｒａｍｉｎｇ ＲＴＰ ａｎｄ ＲＴＣＰ Ｐａｃｋｅｔｓ ｏｖｅｒ Ｃｏｎｎｅｃｔｉｏｎ−Ｏｒｉｅｎｔｅｄ Ｔｒａｎｓｐｏｒｔ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月５日）
【非特許文献１１】「Ａ ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ｎｏｎ−Ａｕｄｉｏ Ｄａｔａ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００４年６月７日）
【発明の開示】
【課題を解決するための手段】
【００１７】
（概要）
本発明の以下の実施形態及び態様は、範囲を限定するものではなく、例示的なものであることを意味するシステムと、ツールと、方法とに関連して説明及び図示される。様々な実施形態では、上述の問題のうちの１つ又は複数が低減又は除去され、他の実施形態は、他の利点又は改善の対象となる。
【００１８】
本開示の一部として、インターネットなどのパケット交換ネットワークを介してファックス・データを通信するシステムが提供される。コンピュータ・ネットワーキング及び電気通信では、パケット交換は、現在主要な通信パラダイムであり、パケット交換では、パケット（情報搬送の単位）が、他の多数のノードで共有される可能性のあるデータ・リンクを介してノード間で個々に経路指定される。一般に、本開示は、ファックス・パケットを得るために、第１ストリーミング・プロトコルを使用して設定されるファックス・データのカプセル化を含み、更に、第２ストリーミング・プロトコルを使用するファックス・パケットのカプセル化を含む。第１ストリーミング・プロトコルは、例えば任意のタイプのファックス中継プロトコルでよく、第２ストリーミング・プロトコルは、例えば任意のタイプのリアル・タイム・プロトコルでよい。
【００１９】
ある実施形態によれば、このシステムは、ソース・ファックス・マシンからファックス信号を受信し、ファックス信号からＴ．３８経路を介してＴ．３８ ＵＤＰＴＬパケットを生成し、ＲＴＰ経路を介して、得られるＴ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にカプセル化し、得られるＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをパケット交換ネットワークに送るように適合された送信ゲートウェイを含むことができる。このシステムは、パケット交換ネットワークからＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットを受信し、ＲＴＰ経路を介してＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをカプセル化解除し、Ｔ．３８経路を介して対応するファックス信号を生成し、対応するファックス信号を目標のファックス・マシン又は受信側ファックス・マシン又は所期のファックス・マシンに送るように適合された受信側ゲートウェイも含むことができる。
【００２０】
本開示の一部として、インターネットなどのパケット交換ネットワークを介してファックス・データを送信するゲートウェイが提供される。ある実施形態によれば、送信側ゲートウェイは、ファックス・マシンからファックス信号を受信し、Ｔ．３８ ＵＤＰＴＬパケットを生成するためにファックス信号を処理し、得られるＴ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にＲＴＰ経路でカプセル化し、例えばパケット・インターフェースを介して、ＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをパケット交換ネットワークに送るように適合されたインバウンドＴ．３８経路を含むことができる。
【００２１】
本開示の一部として、インターネットなどのパケット交換ネットワークを介してファックス関連データを送信する機器が提供される。ある実施形態によれば、この機器は、Ｔ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にカプセル化し、得られるＲＴＰパケットをパケット交換ネットワークに送るように適合されたコントローラを含むことができる。ある実施形態によれば、この機器は、パケット交換ネットワークを介してファックス関連データを受信することができる。こうした実施形態によれば、ＲＴＰヘッダと共にカプセル化されたＴ．３８ ＵＤＰＴＬパケットを受信し、ＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをカプセル化解除するようにコントローラを適合させることもできる。ある実施形態によれば、この装置は、インターネット・アウェア携帯電話、インターネット・アウェア・ファックス、又はインターネット・アウェア・モデムでよい。
【００２２】
本開示の一部として、着信ファックス・データを処理する方法が提供される。ある実施形態によれば、この方法は、Ｔ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にカプセル化することを含むことができる。この方法は、インターネットなどのパケット交換ネットワークにＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットを送ることを更に含むことができる。
【００２３】
本開示の一部として、インターネットなどのパケット交換ネットワークからファックス・データを受信する方法が提供される。ある実施形態によれば、この方法は、パケット交換ネットワークからＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットを受信し、パケットをインターネット・プロトコル・ヘッダからカプセル化解除し、その後ＵＤＰヘッダからカプセル化解除することを含むことができる。
【００２４】
本開示の一部として、ＲＴＰパケットのペイロードは、Ｔ．３８ ＵＤＰＴＬ型ファックス・データ以外のほぼ任意のタイプのファックス・データを含むことができる。即ち、Ｔ．３８ ＵＤＰＴＬプロトコルに準拠する、ファックス・データ以外のほぼ任意のタイプのファックス・データをＲＴＰヘッダと共にカプセル化することができる。より一般には、ＲＴＰパケットのペイロードは、送信側ゲートウェイ（又は他の装置）内のインバウンドＦＲＰ経路、及び受信側ゲートウェイ（又は他の装置）内のアウトバウンドＦＲＰ経路で処理することのできるファックス中継プロトコル（ＦＲＰ）パケット、ＦＲＰ型ファックス・データを含むことができる。本開示に関連して使用されるＦＲＰ（ファックス中継プロトコル）という用語は、パケット交換ネットワークを介するファックス通信を指し、具体的には、ＦＲＰは、今日知られているほぼ任意のＦＲＰ（例えばＴ．３８ ＵＤＰＴＬ）及び将来考案される任意のＦＲＰを包含することを意味する。ＦＲＰは、既存のＴ．３８ ＵＤＰＴＬの将来の拡張と、機能強化と、改良も含むことができる。本開示に関連して使用されるＦＲＰパケットは、ＦＲＰ１次データ（例えば、Ｔ．３０制御及び／又はファックス・イメージ・データ）と、誤りチェック・データ（例えばシーケンス番号）と、任意選択の誤り訂正データとを含むものとする。ＦＲＰは、ファックス中継情報を転送するための信頼性の高いプロトコルであると想定され、ＲＴＰプロトコル又は標準とは無関係に設計、開発、及び使用を可能にすると想定される。
【００２５】
上述の例示的態様及び実施形態に加えて、図を参照することにより、また以下の詳細な説明を検討することにより、別の態様及び実施形態が明らかとなるであろう。
例示的実施形態が、参照される各図に示される。本明細書で開示される実施形態及び図は、限定的なものではなく例示的なものとみなされるべきものとする。しかし、本発明の編成及び動作方法、並びに目的、特徴、利点に関する開示は、以下の詳細な説明を添付の図面と共に参照することによって最良に理解することができる。
【００２６】
なお、図を簡単にし、見やすくするために、図に示される要素は必ずしも原寸に比例しないことを理解されたい。例えば、図が見やすいように、要素の一部の寸法が他の要素に対して誇張されることがある。更に、適切と考えられる場合に、対応する要素又は類似の要素を示すために、参照番号が各図の間で反復されることがある。
【発明を実施するための最良の形態】
【００２７】
以下の詳細な説明では、開示の完全な理解を与えるために多数の特定の詳細が説明される。しかし、こうした特定の詳細なしに本開示を実施できることを当業者は理解されよう。他の場合には、本開示を不明瞭にしないように、周知の方法と、手順と、構成要素と、回路は、詳細には説明されていない。
【００２８】
別段の指示がない限り、以下の議論から明らかなように、明細書全体を通して、「処理」、「計算」、「決定」などの用語を使用する議論は、コンピューティング・システムのレジスタ及び／又はメモリ内の電子的量などの物理的量として表されるデータを操作し、且つ／又はコンピューティング・システムのメモリ、レジスタ又はその他のそのような情報記憶装置、情報伝送装置、又は情報表示装置内の物理量として同様に表される他のデータに変換するコンピュータ又はコンピューティング・システム、或いは同様の電子コンピューティング装置の動作及び／又はプロセスを指すことを理解されたい。
【００２９】
本開示は、完全なハードウェア実施形態、完全なソフトウェア実施形態、又はハードウェア要素とソフトウェア要素をどちらも含む実施形態の形態を取ることができる。好ましい実施形態では、開示が、限定はしないがファームウェア、常駐ソフトウェア、マイクロコードなどを含むソフトウェアで実装される。
【００３０】
本開示の実施形態は、本明細書に記載のオペレーションを実施する機器を含むことができる。この機器を所望の目的のために特別に構築することができ、又はこの機器は、コンピュータに格納されるコンピュータ・プログラムによって選択的に活動化又は再構成される汎用コンピュータを含むことができる。
【００３１】
更に、この開示は、コンピュータ又は任意の命令実行システムで使用され、又はそれと共に使用されるプログラム・コードを提供するコンピュータ使用可能媒体又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態を取ることができる。この説明では、コンピュータ使用可能媒体又はコンピュータ可読媒体は、命令実行システム、機器、又は装置で使用され、又はそれと共に使用されるプログラムを収容、格納、通信、伝播、又は移送することのできる任意の機器でよい。
【００３２】
プログラム・コードを格納及び／又は実行するのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接的又は間接的に結合された少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードの実際の実行中に使用されるローカル・メモリと、バルク・ストレージと、実行中にコードをバルク・ストレージから取り出さなければならない回数を削減するために少なくとも一部のプログラム・コードの一時的記憶を実現するキャッシュ・メモリとを含むことができる。入出力装置又はＩ／Ｏ装置（限定はしないが、キーボード、ディスプレイ、ポインティング・デバイスなどを含む）を、直接的に、又は介在Ｉ／Ｏコントローラを介してシステムに結合することができる。
【００３３】
ネットワーク・アダプタをシステムに結合することもでき、介在プライベートネットワーク又は公衆ネットワークを介してデータ処理システムを他のデータ処理システム或いはリモート・プリンタ又は記憶装置に結合することが可能となる。モデムと、ケーブル・モデムと、イーサネット（登録商標）・カードは、現在利用可能なタイプのネットワーク・アダプタのほんの数例である。
【００３４】
本明細書で提示されるプロセス及びディスプレイは、何らかの特定のコンピュータ又は他の機器に本質的に関連するものではない。本明細書の教示によるプログラムと共に様々な汎用システムを使用することができ、又は所望の方法を実施するためにより特殊な機器を構築することが好都合であることが判明することがある。様々なこうしたシステムに対する所望の構造が、以下の説明から明らかとなる。更に、本開示の実施形態は何らかの特定のプログラミング言語を参照して説明されるわけではない。本明細書で説明される開示の教示を実装するのに様々なプログラミング言語を使用できることを理解されよう。
【００３５】
パケット損失を最小限に抑え、ゲートウェイで受信されるパケットのリオーダリングを容易にするために、送信側ゲートウェイは、別々のパケット・ストリームで、又は送られる１次パケットと共に同一のストリーム内で、補助冗長パケットをＩＰネットワークに送信する。１次パケットは、データ／情報の一部をそれ自体含むパケットである。補助パケットは、使用される保護方法／プロトコルに応じて、２次パケット、反復パケット、冗長パケット、又はＦＥＣパケットとも呼ばれることがある。例えば、Ｔ．３８／ＵＤＰＴＬでは、冗長パケットは、２次（反復）パケット及び／又はＦＥＣメッセージを含むことができる。ＲＴＰでは、２次パケットは冗長パケットと呼ばれ、ＦＥＣは、具体的には前方誤り訂正パケットを指す。そのような補助データ／情報がない場合、パケットは、１次パケットのみからなり、１次パケットは、ＲＴＰヘッダと共にカプセル化されて提供される。
【００３６】
次に図１を参照すると、例示的な基本的ＦｏＩＰ／ＶｏＩＰシステム（全体的に１００で示す）の略図が示されている。２つのファックス・マシン（１０１及び１０２で示す）と、２つのゲートウェイ（１０３及び１０４で示す）と、ＩＰネットワーク１０７からなる例示的ＦｏＩＰ／ＶｏＩＰシステム１００が、示されている。より一般的には、装置１０１及び１０２のそれぞれは、ＵＤＰＴＬ／ＲＴＰパケットをデータ・ネットワークに／から転送／受信する任意のＩＰ使用可能装置でよい。しかし、話を簡単にするために、以後、装置１０１及び１０２を単にファックス装置又はファックス・マシンと呼ぶ。
【００３７】
伝統的に、ファックス・マシンは、公衆交換電話網（「ＰＳＴＮ」）を介してファックス呼を行うように設計されてきた。そのようなファックス呼を管理する方式と、そのようなファックス呼がＰＳＴＮインフラストラクチャを横断する方式とが、参照により本明細書に組み込まれるＩｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ − Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ（「ＩＴＵ−Ｔ」）ｄｉｖｉｓｉｏｎ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｔ．３０（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｄｏｃｕｍｅｎｔ ｆａｃｓｉｍｉｌｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｉｎ ｇｅｎｅｒａｌ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋｓ」）に定義されている。一般には、ファックス・マシン１０１及び１０２などのファックス・マシンは、例えばＰＳＴＮを介するファックス呼横断を可能にするための変調方式を使用する。例えば、ファックス・マシン１０１又は１０２で開始されたファックス呼は、それぞれゲートウェイ１０３又は１０４までのＰＳＴＮ回線接続１０５又は１０６を横断することができる。しかし、ＦｏＩＰ呼を可能にするためには、即ち、ＩＰネットワーク１０７を介してファックス呼を転送するためには、ファックス・マシンによる信号出力が、ＩＰネットワーク１０７を介する伝送に適したビットストリームに変換されなければならない。この変換は、一方が（通常はＰＳＴＮインターフェースを介して）ファックス端末に接続され、他方がＩＰネットワークに接続される媒体ゲートウェイによって実施される。例えば、ゲートウェイ１０３（更には１０４）は、ＰＳＴＮ接続回線１０５（又は１０６）を介してファックス・マシン１０１に接続され、ファックス・マシン１０１（又は１０２）の信号出力をＩＰネットワーク１０７を介する伝送に適したビットストリームに変換する。ゲートウェイ１０３及び１０４は、対応するビットストリームをＩＰネットワーク１０７に転送するためにＩＰネットワーク１０７に接続される（それぞれ１０９及び１０８で示す）。ＩＰネットワーク１０７はインターネットでよいが、他のタイプのＩＰネットワーク、パケット交換ネットワークも使用することができる。ファックス・マシン１０１及び１０２がＩＰ使用可能である場合、ファックス・マシン１０１及び１０２は、それぞれネットワーク接続１１１及び１１２を介して、直接的にパケットをデータ・ネットワーク１０７に転送し、データ・ネットワーク１０７からパケットを受信することができる。
【００３８】
ゲートウェイ１０３及び１０４などのゲートウェイで実施される変換は、ゲートウェイ内のファックス（中継）受信機による着信サンプリング信号の復調、使用されるファックス中継プロトコル（「ＦＲＰ」）による復調後データのパケット化、及び、宛先（受信側）ゲートウェイに向けてのＩＰネットワークへのＦＲＰパケットの送信を含む。受信側ゲートウェイは通常、受信されたＦＲＰパケットを、ＩＴＵ−Ｔ勧告Ｔ．３０で定義される変調方式に従って再復調するファックス中継送信機を含む。次いで、再復調後信号は、ゲートウェイから、所期の／受信側ファックス・マシンに転送され、そこで再復調後信号が復調され、送信側ファックス・マシンによって送られた元のメッセージ／データが抽出される。
【００３９】
ファックス中継は、ＩＰネットワークを介してエンドツーエンド・ファックス通信を高い信頼性で実施することで知られている。ＦｏＩＰシステムのための通信プロトコルが、参照により本明細書に組み込まれるＩＴＵ−Ｔ勧告Ｔ．３８（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｒｅａｌ−ｔｉｍｅ Ｇｒｏｕｐ ３ ｆａｃｓｉｍｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｏｖｅｒ ＩＰ ｎｅｔｗｏｒｋｓ」）に記載されている。一般には、ＩＴＵ−Ｔ Ｔ．３８は、ＦｏＩＰ呼の確立と、Ｇ３タイプ・ファックス呼の異なる信号を転送するパケット・フォーマットとを定義する１組の規則である。
【００４０】
ゲートウェイのＦｏＩＰ部分は、ファックス・マシン１０１及び１０２などの通信する２つのファックス・マシン間で、ファックス・マシンが誤り警報なしにファックス呼／セッションを完了できるような方式で信号を交換することを可能にする。ＦｏＩＰゲートウェイはまた、応答側ファックス・マシンが通信中のゲートウェイからアナログ信号を受信し、「Ｉｎ−Ｍｅｓｓａｇｅ」手順と呼ばれるプロトコル手順を使用することによって応答側ファックス・マシンに転送されたバイナリ情報を抽出することを可能にする。次いで、応答側ファックス・マシンは、発信側ファックス・マシンが意図したように、受信したアナログ信号を解釈することができる。通常、ファックス中継ゲートウェイ（ゲートウェイ１０３及び１０４など）は、ファックス呼の始めから、ファックス呼の間全体にわたって、すべてのタイプのファックス信号を検出し、復調し、再復調する。
【００４１】
装置１１３及び１１４は、インターネット・アウェア装置であり、携帯電話、ファックス装置、又はモデムでよい。インターネット・アウェア装置１１３及び１１４は、例えば互いに、ファックス・マシン１０１又は１０２と、又は他のＩＰファックス使用可能装置（図示せず）とファックス関連データ又は情報を通信又は交換することが可能となるように、ファックス送信機能及び／又は受信機能を有することができる。インターネット・アウェア装置１１３及び１１４は、例えば、それぞれ接続回線１１５及び１１６を介してパケットを転送することができ、且つ／又はＩＰネットワーク１０７からパケットを受信することができる。インターネット・アウェア装置１１３及び１１４は、異なるイメージ・フォーマットでファックス・イメージを転送（及び／又は受信）することができる。
【００４２】
伝統的に、ゲートウェイ１０３及び１０４などのゲートウェイのＶｏＩＰ部分は、８ｋＨｚ以上のサンプリング・レートで入力及び出力音声帯域信号を処理する。ゲートウェイは、インターフェース回路を介してアナログ装置と信号を交換する。図１の各装置が適切な入出力（Ｉ／Ｏ）インターフェースと、反響消去回路と、呼／信号識別回路とを含み、適切な呼確立手順及びその他の前／後処理手順を使用する仮定するが、これらの回路及び手順は本開示の一部ではなく、従って本明細書では参照されない。通常、入力サンプルは、標準変調方式に従ってデジタル・ビットストリームによって変調された正弦波形（搬送波）信号を表す。変調ビットストリームは、ファックス機能、コマンド、応答、イメージ・ビット・マップ、転送されるバイナリ・ファイル、混合ラスタ内容などの有用な情報を含むことができる。
【００４３】
次に図２（従来技術）を参照すると、ファックス通信で使用されるＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰパケットの一般的構造（２００で示す）が、示されている。第１ファックス中継モデルの１つであり、最も使用されるモデルである図２に示されるモデルを、図１に関連して以下で説明する。図１のファックス・マシン１０１からファックス・マシン１０２にファックス通信を送信するために、ファックス・マシン１０１は、ファックス信号（Ｔ．３０制御又はスキャンされたファックス・イメージの変調後データ）を生成し、生成したファックス信号を、（例えば、ＰＳＴＮ回線接続線１０５を介して）互いに通信中の図１のゲートウェイ１０３に転送する。ゲートウェイ１０３は、ゲートウェイ１０３に転送されたファックス・データ／信号をパケット化し、ＩＦＰパケットを形成する。次いで、ゲートウェイ１０３は、各ＩＦＰパケット２０１を（任意選択で冗長性パケット２０２又はＦＥＣメッセージ２０３と共に）ＵＤＰＴＬヘッダ２０４と共にカプセル化する。ゲートウェイ１０３は更に、ＵＤＰＴＬカプセル化パケットをユーザ・データグラム・プロトコル（「ＵＤＰ」）ヘッダ２０５と共にカプセル化する。最終的に、ゲートウェイ１０３は、ＵＤＰカプセル化パケットをＩＰヘッダ２０６と共にカプセル化する。次いで、ゲートウェイ１０３は、得られたデータ・パケット２００を（幾つかの同様にカプセル化されたパケットの中の１つのパケットでよい）、ネットワーク接続１０９を介してＩＰネットワーク１０７に転送する。受信側ゲートウェイ（この例ではゲートウェイ１０４）は、データ・パケット２００を受信し、それをカプセル化解除し、対応するファックス・データ／信号をファックス・マシン１０２に転送することができる。
【００４４】
次に図３（従来技術）を参照すると、ファックス通信で使用されるＩＦＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造が、示されている。先に説明したように、ＲＴＰプロトコルは元来、ＲＴＰペイロードを構成するリアル・タイム媒体を通信するために設計された。しかし、ＲＴＰプロトコルがファックス・データ／信号を（ＩＴＵ−Ｔで最近提案されたようにＩＦＰパケット３０１の形式などで）通信するために使用されたとき、ＩＦＰパケット３０１と、（任意選択）冗長性パケット３０２又はＦＥＣ情報３０３とがＲＴＰペイロードを構成する。図２及び３に示されるモデルは、第１カプセル化ステージが異なる。即ち、ファックス・データ／信号（例えばファックス・データ／信号２０１）をＵＤＰＴＬヘッダ（図２に示される）と共にカプセル化する代わりに、ファックス・データ／信号（例えばファックス・データ／信号３０１）が、ＲＴＰヘッダ３０４（図３に示される）などのＲＴＰヘッダと共にカプセル化される。
【００４５】
図２及び３に示されるモデルの別の違いは、それらの誤り回復データ・フォーマットに関する。即ち、ＵＤＰＴＬは、Ｔ．３８ ＵＤＰＴＬに従って生成された冗長性又はパリティＦＥＣフレームの使用を可能にし、一方ＲＴＰは、ＲＦＣ ２１９８（３０２）で指定される冗長性データ、又はＲＦＣ ２７３３で指定されるＦＥＣデータ（３０３）の使用を可能にする。
【００４６】
プロトコルの一部として、ＲＴＰヘッダ（例えばＲＴＰヘッダ３０４）は、ＲＴＰペイロードに関する情報を含む。例えば、ＲＴＰヘッダ３０４は、ペイロードのソース、サイズなどに関する情報を含む。データ要素３０１から３０４からなるＲＴＰパケットを、ＩＰネットワークを介してそのまま転送することはできない。ＲＴＰパケットの転送を可能にするために、ＲＴＰパケットをＵＤＰヘッダ３０５と共にカプセル化し、得られるパケットを（３０６で示される）ＩＰヘッダと共に更にカプセル化することが必要である。次いで、（３００で示される）得られるパケットをＩＰネットワークを介して転送することができる。
【００４７】
ＩＦＰパケット３０１（並びに任意選択でパケット３０２及び３０３）をＲＴＰヘッダ３０４と共にカプセル化することは、ＩＦＰ−ＲＴＰ関係の点で「直接カプセル化」とみなすことができる。生パケットと考えることのできるＩＦＰパケットがそのままＲＴＰヘッダと共にカプセル化されるからである。ＲＴＰを介するＴ．３８ ＩＦＰパケットの伝送（以後「Ｔ．３８ ＩＦＰ／ＲＴＰ」と呼ぶ）、又は図３に概略を示す直接カプセル化の使用は、以下で詳細に説明するように幾つかの欠点を有する。
【００４８】
次に図４を参照すると、本開示のある実施形態によるＴ．３８ ＵＤＰＴＬ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造が、示されている。図３に示す直接カプセル化とは対照的に、図４は、間接カプセル化方法を示し、この間接カプセル化方法によれば、ＩＦＰパケットがまずＵＤＰＴＬヘッダと共にカプセル化され、それによって標準Ｔ．３８ ＵＤＰＴＬパケット（４０１）が形成される。次いで、図２の要素２０１から２０４などの要素からなると考えることのできるＴ．３８ ＵＤＰＴＬパケット４０１がＲＴＰヘッダ（４０２）と共にカプセル化される。最終的に、ＵＤＰ及びＩＰカプセル化（それぞれ４０３及び４０４）が通常通り実施され、ＩＰネットワークを介して転送可能な新規なタイプのパケット（４００）が形成される。
【００４９】
本開示によれば、ファックスが送信側（ソース）ゲートウェイから受信側（宛先又は目標）ゲートウェイに送信されるときはいつでも、パケット４００のＲＴＰペイロードはＴ．３８ ＵＤＰＴＬパケットであり、リアル・タイム・データ／信号がソース・ゲートウェイから宛先ゲートウェイに送信されるときはいつでも、パケット４００のＲＴＰペイロードは、例えば符号化音声に典型的なものであることに留意されたい。
【００５０】
図５ａと、５ｂと、６と、７とに関して、要素／ユニットと、パケットと、パケットの部分と、プロセスとが、ファックス及びＲＴＰパケットを送信するゲートウェイに関する説明で参照される。しかし、（ＩＰネットワークから）ファックス及びＲＴＰパケットをそれぞれ受信する状況で、同一のゲートウェイに関する説明で参照されることもある。そのような場合、こうした要素／ユニット、パケット、パケットの部分、又はプロセスが、異なる送信側ゲートウェイに属し、又は異なる送信側ゲートウェイから来ると解釈すべきではない。
【００５１】
次に図５ａを参照すると、図２に示されるパケット・モデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットを通信する従来型ゲートウェイが、示されている。ゲートウェイ５００などの典型的な従来型ゲートウェイは、インバウンド及びアウトバウンドのファックス及び音声／オーディオ通信を共に処理するように設計される。ファックス通信に関する説明のために、インバウンド及びアウトバウンドのファックス・データを処理するＦｏＩＰ部分のみを含むゲートウェイ５００を示す。
【００５２】
例示的ゲートウェイ５００のインバウンド・ファックス・データ／情報処理経路（５０１に示される）は、（発信側ファックス・マシンなどの）ソース・ファックス・マシン（など、図示せず）からのファックス・サンプルを受諾し、サンプルを処理し、対応するＦｏＩＰパケットを（Ｔ．３８ ＵＤＰＴＬフォーマットで）転送する。ファックス受信機５０２は、発信側ファックス・マシン（図示せず）からサンプリングしたファックス信号を（例えば、５０６のファックス・サンプルで）受諾し、サンプリングされた信号を復調し、対応するＴ．３０制御及びファックス・データ５０７を生成することができる。Ｔ．３８ ＩＦＰパケッタイザ５０３は、Ｔ．３０制御又はファックス・イメージ・データ（５０７）からＴ．３８ ＩＦＰパケット（５０８）を生成する。Ｔ．３８ ＵＤＰＴＬパケッタイザ５０４は、Ｔ．３８ ＩＦＰパケット（５０８）をカプセル化し、シーケンス番号と、Ｔ．３８ ＩＦＰと、ＵＤＰＴＬ冗長性パケットとを含むＴ．３８ ＵＤＰＴＬパケット（５０９）を形成する。最終的に、パケット・インターフェース５０５は、Ｔ．３８ ＵＤＰＴＬパケット（５０９）をＩＰヘッダと共にカプセル化し、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ５１０を形成し、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ５１０をＩＰネットワーク（図示せず）に転送する。
【００５３】
ファックス・パケット・ストリームをＩＰネットワークに送信するゲートウェイでは、Ｔ．３８ ＵＤＰＴＬパケッタイザ５０４は、新しい１次ＩＦＰパケットごとに（ＵＤＰＴＬヘッダの）シーケンス番号５３５を生成する。任意選択で、Ｔ．３８ ＵＤＰＴＬパケッタイザ５０４は、Ｔ．３８ ＵＤＰＴＬ冗長性フレーム（５３６）又はＦＥＣフレーム（図示せず）を追加することができる。
【００５４】
例示的ゲートウェイ５００のアウトバウンド・ファックス・データ／情報処理部（５１３）は、ＩＰネットワーク（図示せず）からＴ．３８ ＵＤＰＴＬパケット（ＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ ５２０）を受諾し、Ｔ．３８ ＵＤＰＴＬパケットを処理し、対応する再変調後ファックス信号を、ファックス・データが意図される宛先（受信側）ファックス・マシン（図示せず）に転送する任を担う。ＩＰネットワーク（図示せず）を介して到着したＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ ５２０は、パケット・インターフェース５２１で受信され、パケット・インターフェース５２１は、ＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ ５２０を再カプセル化してＴ．３８ ＵＤＰＴＬパケット（５２２）を抽出する。Ｔ．３８ ＵＤＰＴＬデパケッタイザ５２３は、Ｔ．３８ ＵＤＰＴＬパケット５２２からＵＤＰＴＬシーケンス番号と、Ｔ．３８ ＩＦＰパケットと、冗長性又はＦＥＣフレーム（５２４）とを抽出し、それらをＴ．３８ ＵＤＰＴＬ誤り回復モジュール５２５に転送し、Ｔ．３８ ＵＤＰＴＬ誤り回復モジュール５２５は、それらを使用して、ほぼ誤りのないＴ．３８ ＩＦＰパケット（５２６）を再構築する。次いで、ほぼ誤りのないＴ．３８ ＩＦＰパケット５２６がＴ．３８デコーダ５２７で復号化され、Ｔ．３０制御及びファックス・イメージ・データ（５２８）が得られる。Ｔ．３０制御及びファックス・イメージ・データ５２８をＴ．３０／イメージ・データ・バッファ５２９に格納することができる。
【００５５】
ファックス（Ｔ．３８型）パケット・ストリームを受信するゲートウェイは、パケット損失を検出し、パケットが順序が狂ってゲートウェイ５００に到着した場合にパケットをリオーダし、ＩＰネットワークで失われたパケットを回復する。ファックス送信機５３０は、Ｔ．３０／イメージ・データ５２８／５２９を再復調し、ＩＴＵ−Ｔ勧告Ｔ．３０に従ってファックス信号／トーン（Ｆａｘ Ｓａｍｐｌｅｓ Ｏｕｔ ５３１）を受信側／所期のファックス・マシンに転送する。
【００５６】
ファックス中継状態マシン５１１は、ファックス受信機５０２（５１２に示される）及びファックス送信機５３０（５３２に示される）を制御する。状態マシン５１１は、通信ゲートウェイ間でタイムスタンプを転送する必要がない。状態マシン５１１は、受信機５０２及び送信機５３０の現ステータス、ＩＰネットワークを介して交換されるＩＦＰデータの量、Ｔ．３０勧告で定義されるＧ３ファックス・オペレーションの一般的規則を考慮に入れる。ファックス中継状態マシンの基本原理は本発明の主題ではない。
【００５７】
次に図５ｂを参照すると、ＩＰネットワークを介してＲＴＰパケット・ストリームを通信する従来型ゲートウェイのブロック図が、示されている。ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ５５１などのＲＴＰ型パケットをＩＰネットワーク（図示せず）に送信するゲートウェイ（例えばゲートウェイ５６０）は、スピーチ／ボイス・エンコーダ（例えばボイス・エンコーダ５７０）などの媒体ソース・モジュール、ＲＴＰパケッタイザ５７１などのＲＴＰパケッタイザを含み、ボイス・エンコーダ５７０は、ボイスエンコーダ５７０への信号入力を符号化し（Ｓａｍｐｌｅｓ Ｉｎ ５６１）、それから、対応するＲＴＰ１次パケット情報（５７２に示される）を生成する。次いで、ＲＴＰ１次信号がＲＴＰパケッタイザ５７１に転送され（５７３で示される）、ＲＴＰパケッタイザ５７１は、ＲＴＰ１次信号をパケット化して、ヘッダ５７９及び１次パケット５７２を有するＲＴＰパケット５７８をペイロードとして得る。任意選択で、ペイロードは、冗長性データ５７６を含むことができる。パケッタイザ５７１で生成されたヘッダ５７９はとりわけ、対応するＲＴＰペイロード・タイプ識別子と、シーケンス番号と、Ｔｉｍｅ ５７７によって生成され、ＲＴＰパケッタイザ５７１に転送されるタイムスタンプとを含むことができる。冗長性パケットがペイロードに含まれる場合、ヘッダ５７９は、１次パケットに対する各冗長パケットのタイムスタンプ・オフセット及びペイロード・タイプのリストを含むことができる。次いで、ＲＴＰパケット５７９は、パケット・インターフェース５８０に転送され（５７４で示される）、パケット・インターフェース５８０は、ＲＴＰパケットをＵＤＰヘッダと共にカプセル化し、その後で、ＩＰヘッダと共にカプセル化し（５５０で示される）、それによって対応するＶｏＩＰパケット（ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ５５１）を生成し、次いでそれをＩＰネットワーク（図示せず）に送信することができる。
【００５８】
ＲＴＰパケットを受信するゲートウェイは通常、１次パケット並びにタイムスタンプ及び／又はタイムスタンプ・オフセットを使用することにより、パケット損失を検出し、パケットの順序が狂ってゲートウェイに到着した場合にパケットをリオーダし、ネットワークで失われたパケットを回復し、「プレイアウト」バッファを構築し、「プレイアウト」バッファにデータをロードする。「プレイアウト・バッファ」とは、所期のモジュールが「データを再生する」ときにジッタがほぼ回避される方式で、格納された音声／オーディオ関連データがそこから取り出され／フェッチされ、所期のモジュールに送られるバッファを意味する。ゲートウェイは、スピーチ・デコーダ（例えばＶｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ５９８）のような媒体モジュールを使用することによってバッファを再生することができる。ゲートウェイがＲＴＰヘッダ（例えばヘッダ５７９）で指定されるペイロード・タイプを識別した後、異なる媒体タイプ間の切換えは、ゲートウェイによって自律的に行われる。
【００５９】
ＶｏＩＰ Ｐａｃｋｅｔ Ｉｎ（５５２）などのＲＴＰパケットをパケット・インターフェース５８１で受信することができ、パケット・インターフェース５８１は、それをカプセル化解除して、ＲＴＰパケット（例えばＲＴＰパケット５７８）を抽出することができる。ＲＴＰヘッダ（例えばヘッダ５７９）を統計評価のためにＲＴＣＰ Ｓｔａｔｉｓｔｉｃｓ ５９３に転送することができる（５９２）。ＲＴＰパケット全体は、ＲＴＰデパケッタイザ５９１に（５９０で）転送され、ＲＴＰペイロードであるシーケンス番号と、ＲＴＰタイムスタンプと、１次パケットと、冗長性とが抽出され、これらは、パケット損失を検出し、パケットをリオーダし（パケットの順序が狂ってゲートウェイに到着した場合）、ネットワークで失われたパケットを回復するなどのために、ＲＴＰエラー回復５９５で使用される。１次パケット・ペイロードを「プレイアウト」バッファ５９５内に適時に整列し、リモート・ゲートウェイがペイロードを送信した元のシーケンスを復元又は回復するために、ＩＰ Ｔｉｍｅ ５９６は、ＲＴＰタイムスタンプ（５９７で示される）（及び／又はタイムスタンプ・オフセット）を使用することができる。
【００６０】
ゲートウェイ５６０は、ＲＴＰデコーダ・プロセスを使用することによってバッファを再生し、例えばＶｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ５９８などのスピーチ・デコーダでバッファを使用することができる。同期（周期的）ビット・ストリーム（例えば、圧縮オーディオ信号に関する同期ビット・ストリーム）がリモート（送信側）ゲートウェイから受信側ゲートウェイに送信される場合、受信側ゲートウェイのボイス・デコーダ（例えば図５ｂのＶｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ５９８）は、受信側ゲートウェイに到着するデータの平均ビット・レートに近いビット・レートを使用して、プレイアウト・バッファ５９５などのプレイアウト・バッファからデータを読み取る。非同期データ（例えばＤＴＭＦ中継コマンド）が受信側ゲートウェイで受信される場合、受信側ゲートウェイのデコーダは、非同期データと共に受信されたタイムスタンプを使用して、元のタイム・シーケンスを複製し、再生し、再構築し、又は復元する。次いで、デコーダの出力信号を、サンプリングされた信号（Ｓａｍｐｌｅｓ Ｏｕｔ ５６２）の形で所期のマルチメディア（図示せず）に転送することができる。「元のタイム・シーケンス」とは、アウトバウンド・データをＩＰデータ・ネットワークに送信する前に送信側ゲートウェイによってアウトバウンド・データに割り当てられたタイム・シーケンスを意味する。
【００６１】
ゲートウェイ５００などの従来のゲートウェイは通常、ファックス通信とＲＴＰ通信をどちらも可能にするために、図５ｂに示し、図５ｂに関連して説明されるユニットも含むことに留意されたい。そのようなゲートウェイのＦｏＩＰ部分及びＲＴＰ部分が、単に説明がわかりやすいようにする目的で、異なる図（図５ａ及び図５ｂ）に示される。
【００６２】
次に図６を参照すると、図３に示されるパケット・モデルに準拠する構造のパケットを通信する例示的ゲートウェイの略図が、示されている。ゲートウェイ６００のインバウンド経路６０１は、ファックス受信機６０２と、Ｔ．３８ ＩＦＰパケッタイザ６０３と、パケット・インターフェース６０５と、状態マシン６１１とを含み、これらは、それぞれ図５ａのファックス受信機５０２と、Ｔ．３８ ＩＦＰパケッタイザ５０３と、パケット・インターフェース５０５と、状態マシン５１１とほぼ同様に機能する。先に説明したように、ＲＴＰプロトコルの一部として、パケットがＩＰネットワークに送信される前にパケットのそれぞれをタイムスタンプしなければならない。従って、Ｔｉｍｅ ６７７（図５ｂのＴｉｍｅ ５７７とほぼ同様に機能する）は、時間情報を生成し、全ＲＴＰパケットを全体としてタイムスタンプするためにＲＴＰパケッタイザ６４９に転送する（６５０で示される）。ＲＴＰプロトコルの一部として、ＲＴＰパケッタイザ６４９は、ＲＴＰペイロードとしてＲＴＰヘッダ及びＴ．３８ ＩＦＰとＲＴＰ冗長性パケットとからなるＲＴＰパケット（６５１で示される）をパケット・インターフェース６０５に転送する。次いで、パケット・インターフェース６０５は、ＲＴＰパケット（ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ６１０）をＵＤＰ及びＩＰヘッダと共にカプセル化した後に、ＲＴＰパケットをＩＰネットワーク（図示せず）に送信することができる。
【００６３】
ゲートウェイ６００のアウトバウンド経路６１２は通常、異なるタイプの媒体で共通に使用される入出力サンプル及びパケット・インターフェースを含むことができる。Ｔ．３８ユニット６２７、６２９、及び６３０は、図５ａのユニット５２７、５２９、及び５３０とそれぞれほぼ同様に機能する。ＲＴＰユニット６４１、６４３、６４５、及び６４６は、それぞれ図５ｂのユニット５９１、５９３、５９５、及び５９６と同様に通常のＲＴＰパケット処理を実施する。ゲートウェイ６００は、図５ｂのＲＴＰ経路使用可能ユニットも含むことができる（インバウンド経路とアウトバウンド経路の両方）。
【００６４】
（ＲＴＰを介するＴ．３８ ＩＦＰパケットの通信に伴う問題）
（図５ａで例示した）Ｔ．３８ ＩＦＰ／ＵＤＰＴＬプロトコルは、特にＦｏＩＰ通信を可能にするように設計されたので、（図６で例示した）Ｔ．３８ ＩＦＰ／ＲＴＰプロトコルと比較して、信頼性及びファックス通信での相互運用性がずっと低い。Ｔ．３８ ＩＦＰ／ＲＴＰモデルは、以下で説明するように幾つかの欠点を有する。例えば、Ｔ．３８ ＩＦＰパケット・ストリームは、非同期の性質であることを意味し、そのためにＴ．３８ ＩＦＰパケットがソース・ゲートウェイでのファックス中継で処理中に、Ｔ．３８ ＩＦＰパケットはタイムスタンプされない。宛先ゲートウェイでは、ファックス中継はパケットの回復のためにタイムスタンプをシークしていない。即ち、ＲＴＰパケッタイザとは異なり、Ｔ．３８送信機及びＴ．３８受信機は、パケットをタイムスタンプしない。一方、ＲＴＰ型データ・ストリーム、具体的にはＲＦＣ ２１９８に準拠するデータ・ストリームは、同期通信向けに設計され、従ってデータ・パケットのタイムスタンピングは、デコーダでの正確な再生を可能にするためにＲＴＰモデルで主要な役割を果たす。
【００６５】
更に、Ｔ．３８ ＵＤＰＴＬの幾つかの機能、例えばパケット複製（受信側ゲートウェイで紛失パケットの回復を可能にするために、パケットをＩＰネットワークに送信するゲートウェイによって適用される機能）と、パケット・リオーダを可能にすることは、以下で詳細に説明するように、ＲＴＰプロトコルとの競合のためにＴ．３８ ＩＦＰ／ＲＴＰ（図６）には適用することができない。
【００６６】
通常のＴ．３８ ＩＦＰパケッタイザは、グループでのＩＦＰパケットの伝送を可能にする。任意のグループ内のパケットを同時に生成することができる。しかし、ＲＴＰプロトコルの一部として、あらゆるパケットが、更に処理され、ＩＰネットワークに送信される前に、Ｔｉｍｅ ６７７によってタイムスタンプされる（例えば、図６の６４７で示される）。従って、図６で例示されるＴ．３８ ＩＦＰ／ＲＴＰは、伝送時間が同一の同時に送信されたＩＦＰパケットのタイムスタンピングを必然的に伴う。しかし、ＲＴＰプロトコルと、グループ内のパケットを同時にタイムスタンプすることの間に矛盾が存在する。ＲＴＰプロトコルによれば、所与のタイムスタンプに割り当てることのできるパケットは１つだけであるからである。従って、正当なＴ．３８ ＩＦＰの機能であるパケットの同時伝送が、ＲＴＰに関する矛盾を引き起こす可能性があり、その結果、パケット損失の範囲の如何に関わらず、ＲＴＰを介して転送されたＴ．３８ ＩＦＲパケットを正しく解釈することができなくなる。
【００６７】
図６に戻ると、Ｔ．３８ ＩＦＰパケッタイザ６０３がＴ．３８ ＩＦＰパケットを適時に待ち行列化及び配布する（通常のＴ．３８ ＩＦＰパケッタイザ５０３に比べて）追加の機能を有する場合、幾つかのＴ．３８ ＩＦＰパケットが同一のタイムスタンプを有するというファックス・パケット・バースト／グループの問題を解決することができる。パケット・バースト問題の他の解決策は、Ｔ．３８パケット化（６０３）のステージでタイムスタンプ（６４７）を適用し、後にこうしたスタンプを、Ｔｉｍｅ ６７７からの通常のタイムスタンプの代わりにＲＴＰパケッタイザ（６４９）で使用することである。この解決策は、追加の遅延を導入しないので、適時にＩＦＰパケットを配布することよりも良いが、通常のＴ．３８ ＩＦＰパケッタイザ５０３に対してＴ．３８ ＩＦＰパケッタイザ（６０３）、及び通常のＲＴＰパケッタイザ５７１に対してＲＴＰパケッタイザ（６４９）という２つのモジュールの変更を必要とする。
【００６８】
（パケット・ストリーム：ＲＴＰオーディオ・パケットに対するＴ．３８ ＩＦＰパケット）
ファックス中継パケット（Ｔ．３８ ＩＦＰパケット）ストリームとオーディオ・パケット（ＲＴＰオーディオ・パケット）ストリームとの違いの幾つかを以下で説明する。ＲＴＰオーディオ・パケット・ストリームは通常、完全２重及び同期式（大部分は周期的）である。即ち、通信に関係する２つのゲートウェイのそれぞれが、ＩＰネットワークにオーディオ関連パケットを周期的に転送する。宛先ゲートウェイとして働くゲートウェイは、ソース・ゲートウェイとして働くゲートウェイに対して同期式にオーディオ・パケットを復号化（再生）する。即ち、オーディオ関連データ・ストリームは、両方の（送信側及び受信側）ゲートウェイによってほぼ同一のビット・レートで処理される。オーディオ・ゲートウェイの１つの目標は、エンドツーエンドでひずみ及びジッタが可能な限り最小限に抑えられたオーディオ信号を送達することであるからである。
【００６９】
一方、Ｔ．３８ ＩＦＰパケット・ストリームは一般に、擬似ランダム・パケット送信／受信間隔の半２重及び非同期データ・ストリームである。Ｔ．３８ ＩＦＰパケット・ストリームは、（時折、同期データについて）パケットのバースト（グループ）からなる可能性があり、パケットのバーストは、送信側ゲートウェイによって同時に生成されることがあり、或いはＴ．３８ ＩＦＰパケット・ストリームは、連続するパケット間に長い時間ギャップ又はウィンドウを有することがある。
【００７０】
（Ｔ．３８ ＵＤＰＴＬでのシーケンス番号及びＲＦＣ ３５５０）
Ｔ．３８ ＵＤＰＴＬでは、ファックス中継セッションの最初に送られる初期ＦｏＩＰパケットのシーケンス番号が、ゼロであるべきであり、ファックス復調器から出力される新しいＩＦＰ１次パケットごとに、連続する送信パケットのシーケンス番号が１だけ増分される。しかし、Ｔ．３８ ＩＦＰパケットが複製される場合、複製されたパケットのシーケンス番号は、先に送られたパケットに対して増分されず、複製されたパケットは、そのパケットが再現する元のパケットと同一のシーケンス番号を有する。一般には、ＵＤＰＴＬパケット・シーケンス番号は、到着ストリーム中の正しいパケット・シーケンスを識別するのに使用される。タイムスタンプ及び時間オフセットは不要であり、Ｔ．３８ ＵＤＰＴＬプロトコルでも使用されない。従って、ファックス中継変調器は、（Ｔ．３８パケットを送信するゲートウェイ内の）リモート・ファックス復調器で発生したファックス信号のタイム・シーケンスを復元する必要がない。Ｔ．３８パケットを受信するゲートウェイは、リモート・ゲートウェイから受信したＴ．３０制御メッセージ／コマンドを拒絶又は置換することが可能である。Ｔ．３８パケットを受信するゲートウェイ内のファックス中継変調器は、それに接続されたファックス・マシンに、元のファックス・メッセージがＩＰネットワークを介して転送されたビット・レートとは異なるビット・レートで（例えばＰＳＴＮを介して）データ／信号を送信することができる。Ｔ．３８モジュールの出力信号は、ファックス中継送信機がＩＰネットワークを介して首尾よくファクシミリ通信するための主要件であるファクシミリ伝送に関するＴ．３０勧告で定義された手順に準拠すべきである。送信側ゲートウェイから受信されたＴ．３８ ＩＦＰパケットの正しいシーケンスは、タイミング・シーケンスに勝る重要な意味を持つ。ゲートウェイがＧ３ファックス通信にとって受け入れられる信号シーケンスを送信した場合であっても、ゲートウェイが変調のためのバイナリ・データを失った場合、ファックス・セッションが失敗する可能性がある。
【００７１】
Ｔ．３８ ＵＤＰＴＬとは対照的に、且つＲＦＣ ３５５０に準拠して、第１ＲＴＰパケットに割り当てられた初期シーケンス番号は、ランダムであるべきであり、ＲＴＰシーケンス番号は、送信側ゲートウェイによってＩＰネットワークに転送される次のＲＴＰデータ・パケットごとに１だけ増分されるべきである。シーケンス番号を増分することは、ペイロード（媒体）タイプとは無関係に実施される。シーケンス番号は、パケット損失を検出し、パケット・シーケンスを復元するために受信側ゲートウェイで使用される。しかし、パケット損失を検出及び回復することは、シーケンス番号だけを使用することでは行うことができない。例えば、ゲートウェイは、（異なるペイロード・タイプを有する）圧縮オーディオ及びＤＴＭＦストリームをＩＰネットワークに送信することができる。ＤＴＭＦ中継パケットは、ネットワーク内で失われる可能性があるのに対して、圧縮オーディオ・ストリームに関するあらゆるパケットは首尾よくその宛先（例えば受信側ゲートウェイ）に到達する。受信側ゲートウェイは、パケット損失を検出することができるが、パケット損失を受ける媒体タイプ・ストリームの識別、及び誤り回復の目的ではパケット損失を検出することができず、ゲートウェイは、区間タイムスタンプを必要とする。パケット損失に関連する統計は、受信されたシーケンス番号に基づき、パケット損失に関連する統計が必要とされる所がどこであっても、標準ＲＴＣＰプロトコルを使用してレポートすることができる。
【００７２】
（タイムスタンプ）
ファックス中継ゲートウェイは、送信されたＦｏＩＰパケットをタイムスタンプせず、ＦｏＩＰパケットを受信したとき、ファックス信号を所期のファックス・マシンに送信するためにタイムスタンプを必要ともしない。Ｔ．３８プロトコルとは対照的に、あらゆる１次ＲＴＰパケットは、ＲＦＣ ３５５０に従うタイムスタンプを有し、あらゆる冗長パケットは、ＲＦＣ ２１９８に従うタイムスタンプ・オフセットを有する。タイムスタンプ及びタイムスタンプ・オフセットは、誤り回復及び信号フローの再構築のためにＲＴＰ受信機によって使用され、ＲＴＰ受信機がそのプレイアウト・バッファを正しく再生することを可能にする。ゲートウェイ間の同期データ転送中のパケット損失の場合、パケットが固定の持続時間を有すると仮定して、特定のペイロード・タイプに関係する紛失パケットの数をタイムスタンプから導出することができる。しかし、非同期データ転送中に失われたパケット、又は可変フレーム持続期間に関しては、タイムスタンプは役に立たない。非同期データ転送中の紛失パケットの問題を克服するために、受信側ゲートウェイは、ＲＦＣ ３５５０及びＲＦＣ ２１９８プロトコルで説明され、又は提案されているものよりもずっと複雑な媒体特性、媒体プロトコル機能強化又は技法を使用する。非同期ＲＴＰ転送の一例は、ＤＴＭＦと、電話と、単純なモデム信号用に設計されたＲＦＣ ２８３３仕様を有するＤＴＭＦ中継に関連する。しかし、ＡＶＴフォーラムは、ファックス中継データ転送専用のＲＦＣをまだ提案しておらず、Ｔ．３８ ＵＤＰＴＬよりずっと良いＲＦＣを予期することができない。
【００７３】
（Ｔ．３８ ＩＦＰパケット複製）
Ｔ．３８ ＩＦＰ／ＵＤＰＴＬでは、ファックス・パケットの複製は、ファックス中継の信頼性を高める。従って、非常に重要なパケットに関して、例えばＴ．３０ ＮＤＩＣＡＴＯＲ、Ｔ．３０ ＤＡＴＡ ＨＤＬＣ−ＯＫ／ＢＡＤ、Ｔ．３０ ＤＡＴＡ ＳＩＧＮＡＬ−ＥＮＤなどに関係又は関連するパケットに関して複製を実施することができる。
【００７４】
Ｔ．３８ ＩＦＰ／ＵＤＰＴＬプロトコルとは対照的に、Ｔ．３８ ＩＦＰ／ＲＴＰゲートウェイは、ＲＴＰシーケンス番号を増分せずにパケットを送信することができない。更に、増分されたＲＴＰシーケンス番号を有するＩＦＰパケットの複製を使用することができない。Ｔ．３８受信機は、反復されるＩＦＰデータを新しいバイナリ・データとみなし、その結果、Ｔ．３８ファックス変調器は、例えばＰＳＴＮ回線によってゲートウェイに結合されたファックス・マシンに、無効なバイナリ情報を送信することになる。
【００７５】
（同時に複数のＴ．３８ ＩＦＰパケットの生成）
ＲＴＰプロトコルとは対照的に、Ｔ．３８パケット・ストリームは、ほぼ同時に生成されたパケットのシーケンスを含むことができる。この１つの理由は、関連する制御情報を使用することによって受信側ゲートウェイが適時にインバウンド・データ・ストリームを処理することを可能にするために、制御情報とデータを共に含むファックス信号をほぼ同時に送信及び受信しなければならないことである。例えば、Ｔ．３０ ＤＡＴＡ ＨＤＬＣ−ＤＡＴＡ及びＨＤＬＣ−ＯＫ／ＢＡＤに関係するパケット、又はそれらから導出されるパケットをほぼ同時に生成及び通信することができる。同様に、Ｔ．３０ ＤＡＴＡ ＳＩＧＮＡＬ−ＥＮＤ及びＴ．３０ ＩＮＤＩＣＡＴＯＲ ＮＯ−ＳＩＧＮＡＬに関係するパケット、又はそれらから導出されるパケットをほぼ同時に生成及び通信することができる。Ｔ．３８パケット・ストリームがほぼ同時に生成されたパケットのシーケンスを含むことができる別の理由は、宛先（受信側）ゲートウェイが処理することのできるパケット化間隔と、送出側（送信側）ゲートウェイの作業フレーム持続期間との間に存在する差である。例えば、宛先ゲートウェイの最大パケット化間隔が１０ミリ秒（ｍｓ）であるが、ソース・ゲートウェイの最小フレーム持続期間が２０ｍｓである場合、送信側ゲートウェイは、２つ以上のパケットからなるバーストとしてＴ．３８型データ・ストリームを送信する。ＩＰ使用可能ファックス・マシンは、パケット・バーストも送信することができる。非ＩＰファックス・マシンとは異なり、ＩＰ使用可能ファックス・マシンは、信号復調を実施又は使用せず、その結果ＩＰファックス・マシンは、経時的なコマンド又はデータの配布を処理する必要がないからである。その代わりに、ＩＰ使用可能ファックス・マシンは、単一のパケット・キューを処理する。同一のタイムスタンプでＲＴＰを介して送信されたＴ．３８ ＩＦＰパケットは、プレイアウト・バッファの再構築の段階でＲＴＰ受信機によって拒絶される可能性がある。従って、ＲＴＰを介して中継される通常のＴ．３８セッションは、パケット損失がない場合であっても失敗する可能性がある。
【００７６】
（冗長性レベル）
Ｔ．３８ ＵＤＰＴＬファックス中継セッションの間、ＦｏＩＰ情報の冗長性レベルは、例えばＴ．３０制御コマンドを変更する可能性があり、データが、ファックス・イメージ・データの冗長性レベルよりも高い冗長性レベルで転送される可能性がある。これは、Ｔ．３０制御信号を中継するときに信頼性を高めるのに有用である。ＲＴＰを介して転送されるＴ．３８ ＩＦＰの場合、冗長性レベルの変化は、ＲＴＰパケット化の段階で（転送されるデータのタイプを理解するために）Ｔ．３８ ＩＦＰ復号化を必要とするので問題である。
【００７７】
（Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰ実装問題）
ゲートウェイ・レベルでは、Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰの実装に関連する主な難点は、２つの比較的複雑なモジュールであるＴ．３８モジュールとＲＴＰモジュールを、それらの性能／機能の適合を含めて、適合させ、又は変更する必要があることである。適合は、パケット生成、パケット受信、紛失パケットの回復、及び「順序が狂って」到着したパケットのリオーダを含むすべてのレベルのパケット処理で必要となる可能性がある。ある場合には、ファックス受信機／送信機及びＴ．３８ ＩＦＰエンコーダ／デコーダがＲＴＰ／ＵＤＰＴＬパケッタイザ／デパケッタイザとは異なるハードウェア要素（例えばＤＳＰ）上に物理的に実装される幾つかのケースでは（後者は、例えばＰＣ上に実装することができる）、Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰを実装するのに必要な範囲で「Ｔ．３８経路」を変更することが可能である。ＩＰ使用可能電話及びＩＰ使用可能ファックス・マシンでは、Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰ手法はやはり非常に問題がある。ＩＰ使用可能ファックス・マシンは、タイムスタンプを使用せずにＴ．３８ ＵＤＰＴＬパケットを送信／受信するからであり、そのような装置は、モデムのような信号処理を実施することができないからである。
【００７８】
（代替プロトコル）
ＲＴＰを介して非オーディオ・データを転送することに関連する問題に対するその他の解決策を提供することを試みて、ＡＶＴ Ｉｎｔｅｒｎａｔｉｏｎａｌフォーラムは、ＲＦＣ ３５５０及びＲＦＣ ２１９８プロトコルに対する代替として３つのプロトコルを考案した。（１）ＦＥＣデータ（既に先に述べた）を使用する方式を指定するＲＦＣ ２７３３、（２）例えば、参照により本明細書にその内容全体が組み込まれるＪ．Ｒｅｙ等の「ＲＴＰ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月１５日）に記載されているＲＴＰ再送信ペイロード・フォーマット、（３）例えば、参照により本明細書にその内容全体が組み込まれるＪｏｈｎ Ｌａｚｚａｒｏ（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月５日）「Ｆｒａｍｉｎｇ ＲＴＰ ａｎｄ ＲＴＣＰ Ｐａｃｋｅｔｓ ｏｖｅｒ Ｃｏｎｎｅｃｔｉｏｎ−Ｏｒｉｅｎｔｅｄ Ｔｒａｎｓｐｏｒｔ」に記載されているＲＴＰ ｏｖｅｒ ＴＣＰ。しかし、これらのプロトコルもまた、ＲＦＣ ３５５０及びＲＦＣ ２１９８と比較して使用するのが複雑であり、更には、これらの３つのプロトコルの何れか１つを使用するときに、ファックス中継及びＲＴＰモジュールを構造的且つ機能的に互いに適合させるのがより難しいという点で問題がある。
【００７９】
ＲＦＣ ２１９８の冗長性方式を使用することによって非オーディオ・データ用の新しいフォーマットを定義する試みが、Ｓａｔｉｓｈ Ｍｕｎｄｒａ（Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ， Ｉｎｃ．）によってなされた。この試みは、例えば、参照により本明細書にその内容全体が組み込まれる「Ａ ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ｎｏｎ−Ａｕｄｉｏ Ｄａｔａ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００４年６月７日）に記載されている。ＩＦＰ／ＲＴＰファックス中継に関する問題は、このプロトコルがＴ．３８及びＲＴＰモジュールにかなりの変更を必要とすることである。
【００８０】
次に図７を参照すると、図４に示すモデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットと、本開示のある実施形態によるＲＴＰパケットとを通信するゲートウェイのブロック図が示されている。ゲートウェイ７００のインバウンド経路７０１は、ゲートウェイ７００のファックス・インバウンド経路を形成するユニット７０２、７０３、７０４、及び７７１を含むことができ、ユニット７０２、７０３、及び７０４は一般に、図５ａのゲートウェイ５００内のそれぞれユニット５０２、５０３、及び５０４とほぼ同様に機能する。ゲートウェイ７００のインバウンド経路７０１はまた、ゲートウェイ７００のＲＴＰインバウンド経路を形成するユニット７７０及び７７１も含み、一般に、図５ｂのゲートウェイ５６０内のそれぞれユニット５７０及び５７１とほぼ同様に機能する。ファックス・インバウンド経路とＲＴＰインバウンド経路の両方でユニット７７１（ＲＴＰパケッタイザ７７１）を使用することができ（同時にではない）、ファックス中継状態マシン７１１は一般に、図５ａの状態マシン５１１及び図６の状態マシン６１１とほぼ同様に機能する。ＲＴＰ通信では、Ｔｉｍｅ ７７７は一般に、図５ｂのＴｉｍｅ ５７７とほぼ同様に機能する。ファックス受信モジュールであるファックス受信機７０２は一般に、図５ａのゲートウェイ５００内のファックス受信機５０２とほぼ同様に機能する。即ち、ファックス受信機７０２は、アナログ・ファックス伝送（この例ではＦａｘ Ｓａｍｐｌｅｓ Ｉｎ ７６１）をファックス・データ・セット（この例では、Ｔ．３０制御及びファックス・イメージ・データ７６４）に変換することができる。ＦｏＩＰパケットでは、パケット・インターフェース７０５は一般に、図５ａのゲートウェイ５００内のパケット・インターフェース５０５とほぼ同様に機能するのに対して、ＲＴＰパケットパケット・インターフェース７０５は一般に、図５ｂのゲートウェイ５６０内のパケット・インターフェース５８０とほぼ同様に機能する。Ｔ．３８ ＩＦＰパケッタイザ７０３と、Ｔ．３８ ＵＤＰＴＬパケッタイザ７０４と、ＲＴＰパケッタイザ７７１は、ＩＰ通信モジュールを形成することができ、ＩＰ通信モジュールはまず、第１ストリーミング・プロトコル（この例ではＴ．３８ ＵＤＰＴＬ）を使用してファックス・データ・セット（７６４で示される）をカプセル化して、ファックス・パケット（７６６で示される）を得、次いで、第２ストリーミング・プロトコル（この例ではＲＴＰ）を使用して、得られたカプセル化ファックス・パケット（７６６で示される）を更にカプセル化する。
【００８１】
ゲートウェイ７００のアウトバウンド経路７１２は、ユニット７２３、７２５、７２７、７２９、及び７３０を含むことができ、ユニット７２３、７２５、７２７、７２９、及び７３０は、ゲートウェイ７００のファックス・アウトバウンド経路を形成し、一般に図５ａのゲートウェイ５００内のそれぞれユニット５２３、５２５、５２７、５２９、及び５３０とほぼ同様に機能する。ゲートウェイ７００のアウトバウンド経路７１２はまた、ユニット７９１、７９３、７９５、及び７９８も含み、ユニット７９１、７９３、７９５、及び７９８は、ゲートウェイ７００のＲＴＰアウトバウンド経路を形成し、一般に図５ｂのゲートウェイ５６０内のそれぞれユニット５９１、５９３、５９５、５９８とほぼ同様に機能する。ゲートウェイ７００のアウトバウンド経路７１２はまた、ＩＰ Ｔｉｍｅ（図示せず）も含み、ＩＰ Ｔｉｍｅは、図５ｂのゲートウェイ５６０内のＩＰ Ｔｉｍｅ ５９６（又は図６のゲートウェイ６００内のＩＰ Ｔｉｍｅ６４６）とほぼ同様に機能する。
【００８２】
ＦｏＩＰパケットでは、パケット・インターフェース７２１は一般に、図５ａのゲートウェイ５００内のパケット・インターフェース５２１とほぼ同様に機能する。ＲＴＰパケットでは、パケット・インターフェース７２１は一般に、図５ｂのゲートウェイ５６０内のパケット・インターフェース５８１とほぼ同様に機能する。ファックス送信機７３０は一般に、図５ａのゲートウェイ５００内のファックス送信機５３０とほぼ同様に機能する。
【００８３】
図７のゲートウェイ７００のインバウンド経路７０１に関して、ゲートウェイ７００に対する入力ソース（７６０）は、ファックス信号（Ｆａｘ Ｓａｍｐｌｅｓ Ｉｎ ７６１）又は音声（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ７６２）でよく、それらは、ファックス・マシン、マルチメディア装置（図示せず）などから発生又は転送させることができる。本開示は、ＲＴＰを介してファックス通信を通信すると共に、ＲＴＰ関連データ／情報が従来の方式で通信される新規な方式を開示する。本開示の一部として、ゲートウェイ７００が、ファックス・データ、又はＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７１０などのファックス関連データ／情報をＩＰネットワーク（図示せず）に送信するときはいつでも、ＲＴＰパケットのペイロードは、例えばＲＴＰペイロードが基本的Ｔ．３８ ＩＦＰパケットである図３及び６に示される方法とは対照的に、関連するＴ．３８ ＵＤＰＴＬパケット７６３全体である。即ち、Ｔ．３０制御／ファックス・イメージ・データ７６４が、従来通りＴ．３８ ＩＦＰパケッタイザ７０３で処理され、対応する標準Ｔ．３８ ＩＦＰパケット（７６５）が生成される。次いで、得られるＴ．３８ ＩＦＰパケットが、Ｔ．３８ ＵＤＰＴＬパケッタイザ７０４で処理され、対応するＴ．３８ ＵＤＰＴＬパケット（７６６）が生成される。
【００８４】
図６に示すようにＴ．３８ ＩＦＰパケットをタイムスタンプすることは（６４７）、Ｔ．３８ ＵＤＰＴＬパケットの保全性又は従来のフォーマットを破る。従って、そのようなタイムスタンピングを避けることは、従来のＴ．３８ ＵＤＰＴＬフォーマットの保全性、従ってＴ．３８ ＵＤＰＴＬフォーマットに関連する元の利点を維持する。次いで、Ｔ．３８ ＵＤＰＴＬパケット全体（７６６）がＲＴＰパケッタイザ７７１によってＲＴＰペイロードとしてＲＴＰカプセル化される。ＲＴＰカプセル化は、１つのタイムスタンピング・プロセスだけを含む。即ち、ＲＴＰパケット全体だけが、ＲＴＰパケットのペイロードとしてのＲＴＰパケット内のＴ．３８ ＵＤＰＴＬパケットと共にタイムスタンプされる（図７の７５０として示される）。ＲＴＰパケッタイザ７７１によってＲＴＰヘッダと共にカプセル化されたファックス中継（Ｔ．３８ ＵＤＰＴＬ）パケットは、ＲＦＣ ３５５０に従ってフォーマットされる。ファックス中継パケットをパケット・インターフェース７０５に送信する前に、異なる媒体データについて共通の任意選択の暗号化をファックス中継パケットに対して使用することができる。ＲＦＣ ２１９８によるＲＴＰ冗長性又はＲＦＣ ２７３３によるＲＴＰ ＦＥＣはファックス中継データ通信中に使用されない（必要でもない）。ファックス中継データを保護するのに必要な誤り回復データが、通常のファックス通信と同様にＴ．３８ ＵＤＰＴＬを介して転送されるからである。
【００８５】
ゲートウェイ７００のアウトバウンド経路７１２に関して、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７１０などのＦｏＩＰパケットがパケット・インターフェース７２１で受信されるときはいつでも、パケット・インターフェース７２１は、ＦｏＩＰパケットのＩＰ及びＵＤＰヘッダからＦｏＩＰパケットをカプセル化解除し、この場合、ＲＴＰパケットのペイロードを伴うＲＴＰパケットと、ＦｏＩＰパケットとを（Ｔ．３８ ＵＤＰＴＬフォーマットの形式で）抽出する。ＲＴＰパケットのヘッダを、前述のようにＲＴＰプロトコルの従来の特徴である統計評価のために、ＲＴＣＰ７９３で使用することができる。次いで、Ｔ．３８ ＵＤＰＴＬパケットを、Ｔ．３８ ＵＤＰＴＬデパケッタイザ７２３と、Ｔ．３８ ＵＤＰＴＬ誤り回復７２５と、Ｔ．３８デコーダ７２７と、Ｔ．３０／イメージ・データ・バッファ７２９と、ファックス送信機７３０とを含むことのできるＴ．３８経路で従来通り処理することができる。
【００８６】
音声が通信されるときはいつでも、音声は、ゲートウェイ７００で従来の方式で処理される。即ち、音声に関連する信号（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ７６２）がボイス・エンコーダ７７０で符号化され、符号化データがＲＴＰパケッタイザ７７１に転送され（７６８）、ＲＴＰパケッタイザ７７１は、（図７ではなく）図５ｂに示すのと同様に、この時にはＲＴＰヘッダと、１次パケット及び冗長性パケットを含むＲＴＰペイロードとからなるＲＴＰパケット（７５１）をパケット・インターフェース７０５に転送する。次いで、パケット・インターフェース７０５は、ＲＴＰパケット（ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７６７）をＵＤＰヘッダ及びＩＰヘッダと共にカプセル化した後に、ＲＴＰパケットを、ＩＰネットワーク（図示せず）に送信することができ、所期の受信側ゲートウェイに送信することができる。
【００８７】
ゲートウェイ７００のアウトバウンド経路７１２に関して、ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７６７などのＶｏＩＰパケットがパケット・インターフェース７２１で受信されるときはいつでも、パケット・インターフェース７２１は、ＶｏＩＰパケットのＩＰヘッダ及びＵＤＰヘッダからＶｏＩＰパケットをカプセル化解除し、この場合は（標準ＲＴＰフォーマットの）ＶｏＩＰパケットであるＲＴＰパケットをそのＲＴＰペイロードと共に抽出する。ＲＴＣＰ ７９３は、統計評価のためにＲＴＰパケットのヘッダを使用することができる。次いで、ＲＴＰデパケッタイザ７９１と、誤り回復及びＲＴＰプレイアウト・バッファ７９５と、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ（Ｐｌａｙ）７９８とを含むことのできる従来のＲＴＰ経路でＲＴＰパケットを通常通り処理することができる。
【００８８】
ＲＴＰデパケッタイザ７９１によるＲＴＰパケット化解除の結果として、送信されるＲＴＰシーケンス番号、ＲＴＰタイムスタンプ、及び／又はタイムスタンプ・オフセット、１次（ＶｏＩＰ）パケット、並びに冗長性データ又はパケットが抽出され（例えば図５ｂの５９４として示される）、（誤り回復及び）ＲＴＰプレイアウト・バッファ７９５で使用されて、パケット・シーケンスが補正され、又は紛失パケットが回復され、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ７９８での使用のために一時的にパケットが格納される。
【００８９】
図７のゲートウェイは、従来技術のゲートウェイに勝る幾つかの利点を有する。図５ａのゲートウェイ５００に示されるファックス（インバウンド及びアウトバウンド）経路などのファックス経路と、図５ｂのゲートウェイ５６０に示されるＲＴＰ（インバウンド及びアウトバウンド）経路などのＲＴＰ経路の両方を含むゲートウェイに関して、ファックス経路及びＲＴＰ経路は、互いに独立に動作する。ファックス経路及びＲＴＰ経路は、ＲＴＰペイロード（ＲＴＰパケットであってもＴ．３８ ＵＤＰＴＬパケットであっても）が受信側ゲートウェイで識別されると、他の経路（それぞれＴ．３８ ＵＤＰＴＬ又はＲＴＰ）の要件及び機能の如何に関わらず、対応する経路（それぞれＲＴＰ又はＴ．３８ ＵＤＰＴＬ）でペイロードが処理されるという意味で互いに独立に動作する。従って、各タイプの経路の従来の利点が維持される。更に、ファックス通信が図７のゲートウェイ７００などのゲートウェイで実装される場合、ファックス通信は、自律的媒体（ペイロード・タイプ）切換え、セキュア転送、統計評価などのＲＴＰ経路の従来の利点も亨受する。
【００９０】
図６の従来のゲートウェイ６００に関して、図７のゲートウェイ７００は、Ｔ．３８ ＩＦＰの変更或いはＴ．３８ ＩＦＰパケッタイザとＲＴＰパケッタイザの両方の変更を必然的に伴う図６の６４７及び６５０で示されるタイムスタンピング・プロセスを使用するのではなく、通常のＲＴＰで一般に使用される図７の７５０に示されるタイムスタンピング・プロセスを使用する。受信されたＴ．３８ ＵＤＰＴＬ／ＲＴＰパケットのＲＴＰヘッダは、ＲＴＣＰ ｓｔａｔｉｓｔｉｃｓ（７９３）のためだけに使用され、Ｔ．３８ ＵＤＰＴＬデパケッタイザ（７２３）への入力では省略される。パケット損失の保護又は回復のためのＵＤＰＴＬシーケンス番号、冗長性、又はＦＥＣ処理は一般に、通常のＴ．３８ ＵＤＰＴＬ経路で実施される。
【００９１】
更に、ＵＤＰＴＬデータをＲＴＰヘッダと共にカプセル化する結果、ＲＴＰヘッダがＩＦＰデータをカプセル化するときのＲＴＰヘッダのサイズと比較して、ＲＴＰヘッダが小さくなる。一般に、使用される冗長性が多くなるほど、ヘッダ・サイズがより節約される。ＩＦＰ／ＲＴＰでは、ＲＦＣ ２１９８で指定されるように、ＲＴＰヘッダ長は冗長性レベルに比例するのに対して、ＵＤＰＴＬ／ＲＴＰでは、ＲＴＰヘッダは、ＲＦＣ ３５５０で定義される固定のサイズを有する。
【００９２】
図７の新規なゲートウェイに関して、Ｔ．３８ ＵＤＰＴＬ標準及びＲＴＰプロトコルの点で変更は不要である。本明細書で開示される新規なプロトコル（例えばＴ．３８ ＵＤＰＴＬ ｏｖｅｒ ＲＴＰ又はＴ．３８ ＵＤＰＴＬ／ＲＴＰ）は、Ｔ．３８ ＵＤＰＴＬパケットを図７の７０５として示されるパケット・インターフェースに直接送信するのではなく、図７の７７１として示されるＲＴＰパケッタイザへのＴ．３８ ＵＤＰＴＬパケットの比較的単純なリダイレクトを使用する。Ｔ．３８／ＵＤＰＴＬ／ＲＴＰ型パケットがパケット・インターフェース７２１で受信されるとき、新規なゲートウェイ（図７のゲートウェイ７００）は、図６のＲＴＰデパケッタイザ６４１などのＲＴＰデパケッタイザにＲＴＰパケット全体をリダイレクトするのではなく、ＲＴＰパケット・ペイロード（１次ＲＴＰ）を図７のＴ．３８ ＵＤＰＴＬデパケッタイザ７２３などのＴ．３８ ＵＤＦＴＬデパケッタイザにリダイレクトする。
【００９３】
図７のゲートウェイ７００の新規な機能を、図１のインターネット・アウェア装置１１３及び１１４などのインターネット・アウェア装置に結びつけ、埋め込み、又は組み込むことができ、図１のゲートウェイ１０３又は１０４などのゲートウェイを使用することなく、ほぼ本明細書で開示したような新規なストリーミング・プロトコル（例えばＴ．３８ ＵＤＰＴＬ ｏｖｅｒ ＲＴＰ型通信）が可能となる。
【００９４】
一般には、本開示で開示される方法を使用して、今日知られている、又は将来考案されるファックス中継プロトコル又は標準にほぼ準拠することのできるファックス・データ（及び／又はファックス関連データ）をＲＴＰヘッダと共にカプセル化することができる。ＲＴＰヘッダと共にカプセル化された任意のファックス・データ（及び／又はファックス関連データ）を、ＲＴＰパケットのペイロードとして、好ましくはファックス・パケットの形でよいＲＴＰパケット内のファックス・データとしてパケット交換ネットワークを介して通信することができる。例えば、Ｔ．３８経路でファックス・データを処理し、Ｔ．３８ ＵＤＰＴＬ型ファックス・パケット（Ｔ．３８パケットと呼ばれる）を得ることができる。より一般には、ＦＲＰ経路でファックス・データを処理し、ＦＲＰ型ファックス・パケット（ＦＲＰパケット）を得ることができる。ゲートウェイ７００は、ファックス・データ（Ｔ．３８ ＵＤＰＴＬ）の１タイプを処理する例示的ゲートウェイであるのに対して、図８及び９は、第２のタイプのファックス・データ（ＰＲＰ）を指す。
【００９５】
次に図８を参照すると、ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造（８００で示される）が示されている。ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケット８００は、ＲＴＰヘッダ（８０２で示される）と共にカプセル化されたＦＲＰパケット（８０１で示される）を含むことができる。得られるＲＴＰパケットを、ＵＤＰヘッダ（８０３で示される）と共に更にカプセル化することができ、次いでＩＰヘッダ（８０４で示される）と共にカプセル化し、ＦＲＰパケットをＲＴＰパケットとして送信することができる。
【００９６】
次に図９を参照すると、（図８に示されるようなモデルに準拠した構造の）ＦＲＰ（ＦｏＩＰ）パケットと、本開示の幾つかの実施形態によるＲＴＰパケットとを通信するゲートウェイ（全体的に９００で示される）の例示的ブロック図が示されている。ゲートウェイ９００のレイアウト及び機能は、図９のＦＲＰ Ｐｒｉｍａｒｙ ９０３及びＦＲＰパケッタイザ９０４がそれぞれ図７のＴ．３８ ＩＦＰパケッタイザ７０３及びＴ．３８ ＵＤＰＴＬパケッタイザ７０４に置き換わり、ファックス通信に関連するインバウンドＦＲＰ経路を形成することを除いて、ゲートウェイ７００のレイアウト及び機能と同様でよい。同様に、図９のＦＲＰデパケッタイザ９２３と、ＦＲＰ誤り回復９２５と、ＦＲＰデコーダ９２７とが、それぞれ図７のＴ．３８デパケッタイザ７２３と、Ｔ．３８ ＵＤＰＴＬ誤り７２５と、Ｔ．３８デコーダ７２７とに置き換わり、ファックス通信に関連するアウトバウンドＦＲＰ経路を形成する。
【００９７】
ゲートウェイ９００のファックス・インバウンド経路９０１は、図７のファックス受信機７０２と同様に機能する（ファックス受信モジュールである）ファックス受信機９０２と、ＦＲＰ１次パケッタイザ９０３と、ＦＲＰパケッタイザ９０４とを含むことができる。即ち、ファックス受信機９０２は、アナログ・ファックス伝送（この例ではＦａｘ Ｓａｍｐｌｅｓ Ｉｎ ９６１）をファックス・データセット（この例ではＴ．３０制御及びファックス・イメージ・データ９６４）に変換することができる。ＦＲＰ１次パケッタイザ９０３は、Ｔ．３０制御及びＦａｘイメージ・データ９６４から、対応するＦＲＰ１次パケット（９６５で示される）を生成する。ＦＲＰパケッタイザ９０４は、対応するＦＲＰパケット９６６を生成する。ゲートウェイ９００のインバウンド経路９０１はまた、ゲートウェイ９００のＲＴＰインバウンド経路を形成し、図５ｂのゲートウェイ５６０内のそれぞれユニット５７０及び５７１と一般にほぼ同様に機能するユニット９７０及び９７１も含む。ユニット９７１（ＲＴＰパケッタイザ９７１）をファックス・インバウンド経路とＲＴＰインバウンド経路の両方で使用することができる（同時にではない）。状態マシン９１１は一般に、図７の状態マシン７１１とほぼ同様に機能する。ＲＴＰ通信では、Ｔｉｍｅ ９７７は一般に、図７のＴｉｍｅ ７７７とほぼ同様に機能する。パケット・インターフェース９０５は一般に、図７のゲートウェイ７００内のパケット・インターフェース７０５とほぼ同様に機能するのに対して、ＲＴＰパケットでは、パケット・インターフェース９０５は一般に、図７のゲートウェイ７００内のパケット・インターフェース７０５とほぼ同様に機能する。ＦＲＰ１次パケッタイザ９０３と、ＦＲＰパケッタイザ９０４と、ＲＴＰパケッタイザ９７１とは、ＩＰ通信モジュールを形成することができ、ＩＰ通信モジュールは、第１ストリーミング・プロトコル（この例ではＦＲＰ）を使用してファックス・データセット（９６４で示される）をまずカプセル化し、ファックス・パケット（９６６で示される）を得、次いで、第２ストリーミング・プロトコル（この例ではＲＴＰ）を使用して、得られたカプセル化ファックス・パケット（９６６で示される）を更にカプセル化する。
【００９８】
ゲートウェイ９００のファックス・アウトバウンド経路９１２は、ユニット９２３、９２５、９２７、９２９、及び９３０を含むことができる。ゲートウェイ９００のアウトバウンド経路９１２はまた、ゲートウェイ９００のＲＴＰアウトバウンド経路を形成し、図７のゲートウェイ７００内のそれぞれユニット７９１、７９３、７９５、及び７９８と一般にほぼ同様に機能するユニット９９１、９９３、９９５、及び９９８も含む。ゲートウェイ９００のアウトバウンド経路９３２はまた、図５ｂのゲートウェイ５６０内のＩＰ Ｔｉｍｅ ５９６（又は図６のゲートウェイ６００内のＩＰ Ｔｉｍｅ ６４６）とほぼ同様に機能するＩＰ Ｔｉｍｅ（図示せず）も含む。ＦｏＩＰパケットでは、パケット・インターフェース９２１は一般に、図７のゲートウェイ７００内のパケット・インターフェース７２１とほぼ同様に機能する。ＲＴＰパケットでは、パケット・インターフェース９２１は一般に、図７のゲートウェイ７００内のパケット・インターフェース７２１とほぼ同様に機能する。ファックス送信機９３０は一般に、図７のゲートウェイ７００内のファックス送信機７３０とほぼ同様に機能する。
【００９９】
図９のゲートウェイ９００のインバウンド経路９０１に関して、ゲートウェイ９００に対する入力ソース（９６０）は、ファックス信号（Ｆａｘ Ｓａｍｐｌｅｓ Ｉｎ ９６１）又は音声（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ９６２）でよく、それらは、ファックス・マシン、マルチメディア装置（図示せず）などから発生又は転送させることができる。ゲートウェイ７００と同様に、ゲートウェイ９００は、ＲＴＰを介してファックス通信を通信すると共に、ＲＴＰ関連データ／情報が従来の方式で通信されるように設計される。本開示の一部として、ゲートウェイ９００が、ファックス・データ、又はＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９１０などのファックス関連データ／情報をＩＰネットワーク（図示せず）に送信するときはいつでも、ＲＴＰパケットのペイロードは、関連するＦＲＰパケット９６３全体である。即ち、Ｔ．３０制御／ファックス・イメージ・データ９６４が、従来通りＦＲＰ１次パケッタイザ９０３で処理され、対応する標準ＦＲＰ１次パケット（９６５）が生成され、その対応する標準ＦＲＰ１次パケット（９６５）が、ＦＲＰパケッタイザ９０４で処理され、対応するＦＲＰパケット（９６６）が生成される。
【０１００】
ゲートウェイ９００のアウトバウンド経路９１２に関して、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９１０などのＦｏＩＰパケットがパケット・インターフェース９２１で受信されるときはいつでも、パケット・インターフェース９２１は、ＦｏＩＰパケットのＩＰ及びＵＤＰヘッダからＦｏＩＰパケットをカプセル化解除し、この場合、ＲＴＰパケットのペイロードを伴うＲＴＰパケットと、ＦｏＩＰパケットとを（ＦＲＰフォーマットの形式で）抽出する。ＲＴＰパケットのヘッダを、前述のようにＲＴＰプロトコルの従来の特徴である統計評価のために、ＲＴＣＰ９９３で使用することができる。次いで、ＦＲＰパケットを、ＦＲＰデパケッタイザ９２３と、ＦＲＰ誤り回復９２５と、ＦＲＰデコーダ９２７と、Ｔ．３０／イメージ・データ・バッファ９２９と、ファックス送信機９３０とを含むことのできる従来のＦＲＰ経路で従来通り処理することができる。
【０１０１】
音声が通信されるときはいつでも、音声は、ゲートウェイ９００で従来の方式で処理される。即ち、音声に関連する信号（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ９６２）がボイス・エンコーダ９７０で符号化され、符号化データがＲＴＰパケッタイザ９７１に転送され（９６８）、ＲＴＰパケッタイザ９７１は、例えば図５ｂ（それぞれ５７２及び５７６）に示すのと同様に、この時にはＲＴＰヘッダと、１次パケット及び冗長性パケットを含むＲＴＰペイロードとからなるＲＴＰパケット（９５１で示される）をパケット・インターフェース９０５に転送する。次いで、パケット・インターフェース９０５は、ＲＴＰパケット（ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９６７）をＵＤＰヘッダ及びＩＰヘッダと共にカプセル化した後に、ＲＴＰパケットを、ＩＰネットワーク（図示せず）に送信することができ、所期の受信側ゲートウェイ又は他の受信側装置に送信することができる。
【０１０２】
ゲートウェイ９００のアウトバウンド経路９１２に関して、ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９６７などのＶｏＩＰパケットがパケット・インターフェース９２１で受信されるときはいつでも、パケット・インターフェース９２１は、ＶｏＩＰパケットのＩＰヘッダ及びＵＤＰヘッダからＶｏＩＰパケットをカプセル化解除し、この場合は（標準ＲＴＰフォーマットの）ＶｏＩＰパケットであるＲＴＰパケットをそのＲＴＰペイロードと共に抽出する。ＲＴＣＰ９９３は、統計評価のためにＲＴＰパケットのヘッダを使用することができる。次いで、ＲＴＰデパケッタイザ９９１と、ＲＴＰプレイアウト・バッファ９９５と、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ９９８とを含むことのできる従来のＲＴＰ経路でＲＴＰパケットを通常通り処理することができる。
【０１０３】
ＲＴＰデパケッタイザ９９１によるＲＴＰパケット化解除の結果として、送信されるＲＴＰシーケンス番号、ＲＴＰタイムスタンプ、及び／又はタイムスタンプ・オフセット、１次（ＶｏＩＰ）パケット、並びに冗長性データ又はパケットが抽出され（例えば図５ｂの５９４として示される）、（誤り回復及び）ＲＴＰプレイアウト・バッファ９９５で使用されて、パケット・シーケンスが補正され、紛失パケットが回復され、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ９９８での使用のために一時的にパケットが格納される。ゲートウェイ９００などのゲートウェイは、図７のゲートウェイ７００に関連して説明した利点と同様の、従来技術のゲートウェイに勝る幾つかの利点を有する。
【０１０４】
図９の新規なゲートウェイに関して、ＦＲＰ標準及びＲＴＰプロトコルの点で変更は不要である。本明細書で開示される新規なプロトコル（ＦＲＰ ｏｖｅｒ ＲＴＰ又はＦＲＰ／ＲＴＰ）は、ＦＲＰパケットを９０５として示されるパケット・インターフェースに直接送信するのではなく、９７１として示されるＲＴＰパケッタイザへのＦＲＰパケットの比較的単純なリダイレクトを使用する。ＦＲＰ／ＲＴＰ型パケットがパケット・インターフェース９２１で受信されるとき、ゲートウェイ９００は、ＲＴＰデパケッタイザ９９１などのＲＴＰデパケッタイザにＲＴＰパケット全体をリダイレクトするのではなく、ＲＴＰパケット・ペイロード（１次ＲＴＰ）をＦＲＰデパケッタイザ９２３などのＦＲＰデパケッタイザにリダイレクトする。
【０１０５】
図７のゲートウェイ７００と同様に、図９のゲートウェイ９００の新規な機能を、図１のインターネット・アウェア装置１１３及び１１４などのインターネット・アウェア装置に結びつけ、埋め込み、又は組み込むことができ、図１のゲートウェイ１０３又は１０４などのゲートウェイを使用することなく、ほぼ本明細書で開示したような新規なＦＲＰ ｏｖｅｒ ＲＴＰ型通信が可能となる。更に、図７のゲートウェイ７００などのゲートウェイ又は図９のゲートウェイ９００は、コントローラを含むことができる。
【０１０６】
本開示の幾つかの特徴を図示し、本明細書で説明したが、多数の修正と、置換と、変更と、均等物とが当業者には今や思い浮かぶであろう。従って、添付の特許請求の範囲は、本開示の真の精神の中に含まれるすべての修正及び変更を包含するものとする。
【図面の簡単な説明】
【０１０７】
【図１】例示的な基本的ＦｏＩＰ／ＶｏＩＰシステムの略図である。
【図２】ファックス通信で使用されるＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である（従来技術）。
【図３】ＩＦＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である（従来技術）。
【図４】本開示のある実施形態によるＴ．３８ ＵＤＰＴＬ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である。
【図５ａ】図２に示されるパケット・モデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットを通信する従来型ゲートウェイのブロック図である。
【図５ｂ】ＩＰネットワークを介してＲＴＰパケット・ストリームを通信する従来型ゲートウェイのブロック図である。
【図６】図３に示されるパケット・モデルに準拠する構造のＦｏＩＰパケットを通信する例示的な従来型ゲートウェイの略図である。
【図７】図４に示すモデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットと、本開示のある実施形態によるＲＴＰパケットとを通信するゲートウェイの例示的ブロック図である。
【図８】ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である（従来技術）。
【図９】図８に示されるようなモデルに準拠した構造のＦＲＰ（ＦｏＩＰ）パケットと、本開示の幾つかの実施形態によるＲＴＰパケットとを通信するゲートウェイの例示的ブロック図である。
【符号の説明】
【０１０８】
１００ ＦｏＩＰ／ＶｏＩＰシステム
１０１ ファックス・マシン
１０２ ファックス・マシン
１０３ ゲートウェイ
１０４ ゲートウェイ
１０５ ＰＳＴＮ回線接続
１０６ ＰＳＴＮ回線接続
１０７ ＩＰネットワーク
１１１ ネットワーク接続
１１２ ネットワーク接続
１１３ インターネット・アウェア装置
１１４ インターネット・アウェア装置
１１５ 接続回線
１１６ 接続回線
２００ ＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰパケット
２０１ ＩＦＰパケット
２０２ 冗長性パケット
２０３ ＦＥＣメッセージ
２０４ ＵＤＰＴＬヘッダ
２０５ ユーザ・データグラム・プロトコル（「ＵＤＰ」）ヘッダ
２０６ ＩＰヘッダ
３０１ ＩＦＰパケット
３０２ パケット
３０３ パケット
３０４ ＲＴＰヘッダ
４０１ 標準Ｔ．３８ ＵＤＰＴＬパケット
４０２ ＲＴＰヘッダ
５００ ゲートウェイ
５０１ インバウンド・ファックス・データ／情報処理経路
５０２ ファックス受信機
５０３ Ｔ．３８ ＩＦＰパケッタイザ
５０４ Ｔ．３８ ＵＤＰＴＬパケッタイザ
５０５ パケット・インターフェース
５０７ Ｔ．３０制御及びファックス・データ
５０８ Ｔ．３８ ＩＦＰパケット
５０９ Ｔ．３８ ＵＤＰＴＬパケット
５１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
５１１ ファックス中継状態マシン
５２０ ＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ
５２１ パケット・インターフェース
５２２ Ｔ．３８ ＵＤＰＴＬパケット
５２３ Ｔ．３８ ＵＤＰＴＬデパケッタイザ
５２４ ＵＤＰＴＬシーケンス番号、Ｔ．３８ ＩＦＰパケット、冗長性又はＦＥＣフレーム
５２５ Ｔ．３８ ＵＤＰＴＬ誤り回復モジュール
５２６ Ｔ．３８ ＩＦＰパケット
５２７ Ｔ．３８デコーダ
５２８ Ｔ．３０制御及びファックス・イメージ・データ
５２９ Ｔ．３０／イメージ・データ・バッファ
５３０ ファックス送信機
５３１ Ｆａｘ Ｓａｍｐｌｅｓ Ｏｕｔ
５３５ シーケンス番号
５３６ Ｔ．３８ ＵＤＰＴＬ冗長性フレーム
５５１ ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
５５２ ＶｏＩＰ Ｐａｃｋｅｔ Ｉｎ
５６０ ゲートウェイ
５６１ Ｓａｍｐｌｅｓ Ｉｎ
５６２ Ｓａｍｐｌｅｓ Ｏｕｔ
５７０ ボイス・エンコーダ
５７１ ＲＴＰパケッタイザ
５７２ ＲＴＰ１次パケット情報
５７６ 冗長性データ
５７７ Ｔｉｍｅ
５７８ ＲＴＰパケット
５７９ ヘッダ
５８０ パケット・インターフェース
５８１ パケット・インターフェース
５９１ ＲＴＰデパケッタイザ
５９３ ＲＴＣＰ Ｓｔａｔｉｓｔｉｃｓ
５９４ ＲＴＰエラー回復
５９５ プレイアウト・バッファ
５９６ Ｔｉｍｅ
５９７ ＲＴＰタイムスタンプ
５９８ Ｖｏｉｃｅ Ｄｅｃｏｄｅ Ｐｌａｙ
６００ ゲートウェイ
６０１ インバウンド経路
６０２ ファックス受信機
６０３ Ｔ．３８ ＩＦＰパケッタイザ
６０５ パケット・インターフェース
６１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
６１１ 状態マシン
６１２ アウトバウンド経路
６４１ ＲＴＰデパケッタイザ
６４６ ＩＰ Ｔｉｍｅ
６４９ ＲＴＰパケッタイザ
７００ ゲートウェイ
７０１ インバウンド経路
７０２ ファックス受信機
７０３ Ｔ．３８ ＩＦＰパケッタイザ
７０４ Ｔ．３８ ＵＤＰＴＬパケッタイザ
７０５ パケット・インターフェース
７１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
７１１ 状態マシン
７１２ アウトバウンド経路
７２１ パケット・インターフェース
７２３ Ｔ．３８ ＵＤＰＴＬデパケッタイザ
７２５ Ｔ．３８ ＵＤＰＴＬ誤り回復
７２７ Ｔ．３８デコーダ
７２９ Ｔ．３０／イメージ・データ・バッファ
７３０ ファックス送信機
７６０ 入力ソース
７６２ Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ
７６３ Ｔ．３８ ＵＤＰＴＬパケット
７６４ Ｔ．３０制御／ファックス・イメージ・データ
７６５ 標準Ｔ．３８ ＩＦＰパケット
７６６ Ｔ．３８ ＵＤＰＴＬパケット
７６７ ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
７７０ ボイス・エンコーダ
７７１ ＲＴＰパケッタイザ
７７７ Ｔｉｍｅ
７９１ ＲＴＰデパケッタイザ
７９３ ＲＴＣＰ ｓｔａｔｉｓｔｉｃｓ
７９５ 誤り回復及びＲＴＰプレイアウト・バッファ
７９８ Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ（Ｐｌａｙ）
８００ ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケット
８０１ ＦＲＰパケット
８０２ ＲＴＰヘッダ
８０３ ＵＤＰヘッダ
８０４ ＩＰヘッダ
９００ ゲートウェイ
９０１ ファックス・インバウンド経路
９０２ ファックス受信機
９０３ ＦＲＰ１次パケッタイザ
９０４ ＰＲＰパケッタイザ
９０５ パケット・インターフェース
９１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
９１１ 状態マシン
９１２ ファックス・アウトバウンド経路
９２１ パケット・インターフェース
９２３ ＦＲＰデパケッタイザ
９２５ ＦＲＰ誤り回復
９２７ ＦＲＰデコーダ
９２９ Ｔ．３０／イメージ・データ・バッファ
９３０ ファックス送信機
９３２ アウトバウンド経路
９５１ ＲＴＰパケット
９６０ 入力ソース
９６１ Ｆａｘ Ｓａｍｐｌｅｓ Ｉｎ
９６２ Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ
９６３ ＦＲＰパケット
９６４ Ｔ．３０制御／ファックス・イメージ・データ
９６５ 標準ＦＲＰ１次パケット
９６６ ＦＲＰパケット
９６７ ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
９７０ ボイス・エンコーダ
９７１ ＲＴＰパケッタイザ
９７７ Ｔｉｍｅ
９９１ ＲＴＰデパケッタイザ
９９５ ＲＴＰプレイアウト・バッファ
９９８ Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ
【技術分野】
【０００１】
本開示は、一般に、通信システムの分野に関する。より詳細には、本開示は、インターネットを介してファクシミリ・データを通信する方法及び機器に関する。
【背景技術】
【０００２】
広域ネットワーク（ＷＡＮ）は、ローカル・エリア・ネットワーク（ＬＡＮ）を互いに接続するのに使用され、それによって、ある場所のユーザ及びコンピュータが、他の場所のユーザ及びコンピュータと通信することができる。インターネットや類似のインターネット・プロトコル（「ＩＰ」）ベースのネットワーク（以後、より一般的に「ＩＰネットワーク」と呼ぶ）などの進行中のＷＡＮの開発／普及のおかげで、一層多くの人々が、ＩＰネットワークを使用して、音声及びファックス呼を含む、データ、ビデオ、オーディオなどの様々なタイプの情報を交換している（本明細書では、音声及びファックス呼とは、上述のタイプの情報のうちの任意の１つ又は複数に対応する信号を送信又は受信することを可能にし、或いは実際に送信又は受信する任意の呼接続と定義され、本明細書では、そのすべてをより一般的に「ファックス呼」と呼ぶ）。２つの適切なマシン（本明細書では「ファックス」とも呼ぶこともある）間のＩＰネットワークを介するファックス呼の通信は一般に、ゲートウェイを介するファックス・トーン及びファックス・データの送信及び受信が関係するので、そのようなゲートウェイは、インターネット・プロトコルを介するファックス（「ＦｏＩＰ」）と、インターネット・プロトコル（「ＶｏＩＰ」）を介する音声などの他の情報とをどちらも処理するように適合される。従って、ゲートウェイは一般に、そのようなファックス呼を可能にするファックス中継と、口頭通信及びモデム通信を可能にするスピーチ・コーダ及び音声帯域データ（「ＶＤＢ」）経路とを含む。
【０００３】
通信ネットワークでは、「ゲートウェイ」（プロトコル変換器とも呼ばれる）という用語は一般に、異なるプロトコルを使用する別のネットワークとインターフェースするように装備されたネットワーク・ノードを指す。ゲートウェイは一般に、ローカル・エリア・ネットワーク（「ＬＡＮ」）とＷＡＮとの間の共通交点に配置され、システム相互運用性を実現するために、必要に応じてプロトコル変換器、インピーダンス整合装置、レート変換器、障害分離器、信号変換器を含むことができる。プロトコル変換／マッピング・ゲートウェイは、必要なプロトコル変換を実施することにより、異なるネットワーク・プロトコル技術を用いたネットワークを相互接続する。ルータは、ゲートウェイの特殊ケースである。ゲートウェイについての詳細は、「Ａｃｃｅｓｓ Ｇａｔｅｗａｙ」（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｓｏｒｔｉｕｍ、２００５年）から得ることができる。
【０００４】
ファックス及び音声通信に関する特徴及び要件が異なるので、２つの異なるタイプのパケット・ストリームは一般に、２つの異なる動作モードで別個に使用される。第１のタイプのパケット・ストリームは、ＶｏＩＰ通信で使用され、リアル・タイム転送プロトコル（「ＲＴＰ」）パケット・ストリームと呼ばれる。Ａｕｄｉｏ Ｖｉｄｅｏ Ｔｒａｎｓｐｏｒｔ（「ＡＶＴ」） Ｉｎｔｅｒｎｅｔフォーラムと呼ばれる国際フォーラムが、異なるメディア・タイプ及び目的のために、幾つかのＲｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ（「ＲＦＣ」）仕様でＲＴＰプロトコルを定義した。例えば、ＶｏＩＰに関する一般的なＲＦＣは、ＲＦＣ ３５５０（「Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ」）であり、これが、ＲＦＣ １８８９、ＲＦＣ ２１９８（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｕｄｉｏ Ｄａｔａ」）、ＲＦＣ ２７３３（「Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ」）、及びＲＦＣ ２８３３（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ ＤＴＭＦ Ｄｉｇｉｔｓ， Ｔｅｌｅｐｈｏｎｙ Ｔｏｎｅｓ ａｎｄ Ｔｅｌｅｐｈｏｎｙ Ｓｉｇｎａｌｓ」）に取って代わった。
【０００５】
ＲＴＰ経路を介して転送される典型的な信号は、音声信号、デュアル・トーン・マルチフリーケンシ（「ＤＴＭＦ」）信号、回線個別信号方式（「ＣＡＳ」）、ＲＦＣ ２８３３仕様に従って中継され、又は音声帯域データ（「ＶＢＤ」）モードで転送されるモデム信号、ビデオ信号などである。ＲＴＰ及びＲＴＰ関連データを処理するのに使用することのできるＲＴＰ経路は、パケット損失のストリームの暗号化及び／又は保護を容易にする手順と、パケット・リオーダと、その他の手順の使用を含むことができる。異なるタイプのＲＴＰストリーム（例えば、通常の音声、ＤＴＭＦ、ＶＢＤ、ビデオ・データ）間の切換えは、ＲＴＰヘッダ内で転送される（ＲＴＰヘッダ内にカプセル化される）ペイロード・タイプを（固有ストリーム識別子として）使用することによってリアル・タイムに実施される。通常、異なるタイプＲＴＰストリーム間で切り換えることは、通信セッションに関係するゲートウェイ間のリアル・タイム・ネゴシエーションを必要としない。
【０００６】
ファックス・データを通信するために、ＲＴＰ経路をそのまま（適合なしで）使用することを試みることは一般に、通信に関係する装置（例えばゲートウェイ及びファックス・マシン）の信頼性及び相互運用性を著しく低下させる。従って、ＦｏＩＰ通信では、当業者には「Ｔ．３８パケット・ストリーム」として知られる異なるタイプのパケット・ストリームが使用される。Ｔ．３８経路パケット・ストリームはＴ．３８経路で処理される。「Ｔ．３８経路」という用語は一般に、ファックス中継データ・ストリーム（Ｔ．３８パケット・ストリーム）の処理（符号化、復号化、回復など）に関係するゲートウェイ及び関連する処理ルーチンと共に配置することができ、又はそれらと関連付けることのできる電子回路を指す。Ｔ．３８データ・パケットは、Ｔ．３８ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎに従ってフォーマットされ、ＴＣＰ又はＵＤＰＴＬを使用してＩＰネットワークを介して中継される。ファックス信号の大きな遅延を導入するＴ．３８／ＴＣＰプロトコルはまれにしか使用されず、従って、以後このタイプのプロトコルは参照しない。Ｔ．３８／ＵＤＰＴＬトランスポートは、パケット損失のストリームの保護、並びに通信ゲートウェイがＴ．３８ストリーム誤りを個々に補正することを可能にするパケット・リオーダを容易にする手順を含む。これらの手順は、ＵＤＰＴＬシーケンス番号及び誤り保護方式の使用を含む。Ｔ．３８ ＵＤＰＴＬで使用される典型的な誤り回復方法は、「２次パケット」を使用する冗長性機能の使用を含む。別のＵＤＰＴＬ誤り回復方式は、パリティ前方誤り訂正（「ＦＥＣ」）を使用する。最後に述べた２つの手順又は方式は、Ｔ．３８ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎにより完全に説明されている。
【０００７】
各タイプのパケット・ストリームは、以下でより完全に説明するように利点と欠点を有する。例えば、Ｔ．３８／ＵＤＰＴＬプロトコルは、長らくファックス中継で広く使用されている周知のプロトコルであり、異なるベンダのゲートウェイ及びファックス・マシンが高い相互運用性を導入するという利点を有し、このことは、装置（ゲートウェイ、ファックス・マシンなど）のベンダの如何に関わらず、異なるゲートウェイ／ファックス・マシンなどが好都合な方式でファックス・メッセージを交換できることを意味する。更に、Ｔ．３８／ＵＤＰＴＬは、ＵＤＰＴＬパケットの複製を可能にし、ＵＤＰＴＬパケットの少なくとも１つの種類のパケットが、受信側（リモート）ゲートウェイ又は他の装置で完全な状態で受信されることが保証される。例えば、ゲートウェイはパケットの５つのコピー又は複製を生成し、それらをＩＰネットワークを介して受信側ゲートウェイに次々に転送することができ、受信側ゲートウェイは恐らく、元のパケット、又はその複製のうちの少なくとも１つを受信することになる。しかし、ＲＴＰプロトコルとは対照的に、Ｔ．３８／ＵＤＰＴＬプロトコルは暗号化を可能にせず、それにより、情報が傍受の影響を受けやすくなる可能性がある。更に、通常はファックス通信ではリアル・タイム・オーディオ応用例の場合のように重大ではないが、ＵＤＰＴＬパケットはタイム・スタンプされず、従って通信関連の統計を計算又は評価することができない。
【０００８】
ＲＴＰパケット・ストリームに関しては、伝送されるストリーム内の各ＲＴＰパケットには固有のシーケンス番号及びタイムスタンプが割り当てられ、それらを受信側ゲートウェイで使用して、パケットの統計を計算し、通信経路の品質を評価し、順序が狂って受信されたパケットを照合（リオーダ）することができる。例えば、統計計算は、ゲートウェイに到着するパケットの移動時間、遅延、ジッタなどに関係付けることができる。更に、ＲＴＰは、データの暗号化を可能にし、従って、通信されるデータのセキュリティの向上を実現する。しかし、（ゲートウェイによるのと同様に）固有シーケンス番号を各ＲＴＰパケットに割り当てることも、パケットを複製することができないという欠点を有する。
【０００９】
ＲＴＰ及びＴ．３８パケット・ストリームは一般に、互いに独立にゲートウェイによって処理される。所与の通信状態の所与のゲートウェイに関して、ＲＴＰパケット・ストリーム又はＴ．３８型パケット・ストリームをゲートウェイで処理することができるが、両方のタイプを同時に処理することはできない。別の見方をすれば、ファックス・マシンが電話（又はファックス・マシン）として動作する場合、音声（又はファックス・データ）通信に関係するゲートウェイは、それぞれ、ＲＴＰ経路（又はＴ．３８経路）を使用可能にすると同時に、Ｔ．３８経路（又はＲＴＰ経路）を使用不能にする。
【００１０】
従って、ファックス呼が音声通信／ファックス・トーン又はファックス・データの送信を含むときはいつでも、ファックス呼に関係するゲートウェイは、ある動作モード（ＲＴＰやＴ．３８など）から他の動作モード（Ｔ．３８又はＲＴＰ）に切り替わらなければならない。即ち、これらのゲートウェイは、時々、ＲＴＰ経路がＲＴＰパケット・ストリーム（呼のＶｏＩＰ部分）を処理することを可能にすると共にＴ．３８経路を使用不能にし、別の時には、Ｔ．３８／ＵＤＰＴＬ経路がＴ．３８パケット・ストリーム（呼のＦｏＩＰ部分）を処理することを可能にすると共にＲＴＰ経路を使用不能にする。「Ｔ．３８（又はＲＴＰ）経路を使用不能にする」という用語は、Ｔ．３８（又はＲＴＰ）データ・ストリームの処理に通常は関係する電子回路及び／又は（通信進行及び応用例タイプに応じて）ソフトウェア・モジュール／要素を使用不能にすることを指す。通信セッションに関係するゲートウェイがＲＴＰ動作モードとＴ．３８動作モードとの間で正しく切り替わるために、ゲートウェイは、特別なプロトコル又は補助コマンドを使用することによってリアル・タイム・ネゴシエーションを開始することができ、その特別なプロトコル又は補助コマンドを、メディア・ゲートウェイ・コントローラによってゲートウェイに転送し、例えばゲートウェイに到着しようとしている予期されるデータ・ストリームのタイプについてゲートウェイに通知することができる。ゲートウェイがＲＴＰパケット・ストリームとＴ．３８パケット・ストリームの両方を同一の宛先ポートを介して転送する場合（同時にではない）、そのようなリアル・タイム・ネゴシエーションは必須である。
【００１１】
ＲＴＰ動作モードとＴ．３８／ＵＤＰＴＬ動作モードとの間の遷移には問題がある。以下で更に説明するように、２つのゲートウェイ間のリアル・タイム・ネゴシエーションで使用される回路及びプロセスを使用可能／使用不能にすることに加えて、各動作モードで使用される異なる回路及びプロセスを適時に使用可能／使用不能にする必要があるからである。
【００１２】
ＲＴＰ（又はＴ．３８）動作モードとＴ．３８（又はＲＴＰ）動作モードの間の遷移を避けるために、Ｔ．３８機能とＲＴＰ機能を組み合わせる試みが行われている。新しく提案されたＴ．３８ベースのプロトコルによれば、Ｔ．３８／ＵＤＰＴ（又はＩＦＰ／ＵＤＰＴＬ）プロトコルとは対照的に、（Ｔ．３８ ＩＦＰパケット・ストリーム内の）Ｔ．３８ ＩＦＰ１次パケットをＲＴＰヘッダ及び任意選択のＲＴＰ冗長性又はＦＥＣと共にＲＴＰ内にカプセル化してＴ．３８／ＲＴＰ（ＩＦＰ ｏｖｅｒ ＲＴＰ、又は短縮してＩＦＰ／ＲＴＰ）プロトコルを形成すべきである。新しいプロトコル（Ｔ．３８／ＲＴＰ）は、以下で説明するようにＴ．３８／ＵＤＰＴＬに勝る幾つかの利点を有する。例えば、Ｔ．３８／ＲＴＰプロトコルは、様々なタイプのＲＴＰ媒体で共通に使用される通信標準であるセキュアＲＴＰ（「ＳＲＴＰ」）を使用することによってＲＴＰ保護されたファックス中継トランスポートを可能にする。
【００１３】
更に、新しく提案されたＴ．３８／ＲＴＰプロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルとは対照的に、２つの通信ゲートウェイ間のリアル・タイム・ネゴシエーションのための時間を費やすことなく、異なるタイプのＲＴＰペイロードを自動的に区別することによって音声（ＲＴＰを介するオーディオ）及びファックス（ＲＴＰを介するＩＦＰパケット）パケット・ストリームとの間の比較的高速な遷移を可能にする。
【００１４】
更に、ＲＴＰカプセル化は、統計評価のためにＲＴＰ制御プロトコル（「ＲＴＣＰ」）を使用することを可能にする。ＲＴＣＰは、ＲＦＣ ３５５０で定義される。ＲＴＣＰは、リアル・タイム・トランスポート制御プロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を意味し、ＲＴＰパケット・ストリームに関する帯域外制御情報を提供する。ＲＴＣＰの主な機能は、ストリーミング・マルチメディア・セッションの参加者に制御パケットを周期的に送信することにより、ＲＴＰによって提供されるサービス品質に関するフィードバックを提供することである。ＲＴＣＰは、媒体接続に関する統計と、送られたバイト、送られたパケット、失われたパケット、ジッタ、フィードバック、往復遅延などの情報とを収集する。アプリケーションは、この情報を使用して、例えばデータ・フローを制限することによって、又は高圧縮コーデックの代わりに低圧縮コーデックを使用することによってサービス品質を向上させることができる。
【００１５】
新しいＴ．３８／ＲＴＰプロトコルによれば、１次ＩＦＰパケットは、Ｔ．３８ ＵＤＰＴＬフォーマット設定を避け、その代わりに、リアル・タイム媒体データ／信号であるかのようにＲＴＰ経路を通過する。新しいＴ．３８／ＲＴＰプロトコルを実装するために、Ｔ．３８ ＵＤＰＴＬの代わりにＲＦＣ ３５５０が使用される。ファクシミリ通信の保護及び失われたパケットの回復を高め、（リオーダリング）パケットの照合を可能にするために、Ｔ．３８標準は、ＲＦＣ ２１９８で指定される任意選択の冗長性手段を使用すること、或いはＲＦＣ ２７３３で指定されるＦＥＣストリームを使用することを推奨している。ＲＦＣ ２１９８及びＲＦＣ ２７３３の内容は、参照により本明細書に組み込まれる。
【００１６】
新しいＴ．３８／ＲＴＰプロトコルも幾つかの欠点を有する。例えば、ＩＦＰ／ＲＴＰを使用する結果、Ｔ．３８／ＵＤＰＴＬと比較して、しばしば計算資源の消費が著しく増大する。部分的には、より多くの計算資源を使用する必要は、ＲＴＰプロトコルが本来はファックス・データ通信に対処するように設計されていなかったために存在する、異なるＲＴＰ及びＴ．３８／ＵＤＰＴＬ要件間の不一致を克服しようと試みる結果として生じる。更に、ＩＦＰ／ＲＴＰプロトコルで提供される相互運用性は、ファックス・データへのタイムスタンプの適用のために、ＩＦＰ／ＵＤＰＴＬプロトコルと比較して貧弱であることがある。提案されたＩＦＰ−ｏｖｅｒ−ＲＴＰ（ＩＦＰ／ＲＴＰ）プロトコルの他の欠点は、図の説明から明らかとなるであろう。
【非特許文献１】「Ａｃｃｅｓｓ Ｇａｔｅｗａｙｓ」（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｓｏｒｔｉｕｍ、２００５年）
【非特許文献２】ＲＦＣ ３５５０（「Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ」）
【非特許文献３】ＲＦＣ １８８９
【非特許文献４】ＲＦＣ ２１９８（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｕｄｉｏ Ｄａｔａ」）
【非特許文献５】ＲＦＣ ２７３３（「Ａｎ ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｇｅｎｅｒｉｃ Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ」）
【非特許文献６】ＲＦＣ ２８３３（「ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ ＤＴＭＦ Ｄｉｇｉｔｓ， Ｔｅｌｅｐｈｏｎｙ Ｔｏｎｅｓ ａｎｄ Ｔｅｌｅｐｈｏｎｙ Ｓｉｇｎａｌｓ」）
【非特許文献７】ＩＴＵ−Ｔ勧告Ｔ．３８（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｒｅａｌ−ｔｉｍｅ Ｇｒｏｕｐ ３ ｆａｃｓｉｍｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｏｖｅｒ ＩＰ ｎｅｔｗｏｒｋｓ」）
【非特許文献８】Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ（「ＩＴＵ−Ｔ」）ｄｉｖｉｓｉｏｎ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｔ．３０（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｄｏｃｕｍｅｎｔ ｆａｃｓｉｍｉｌｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｉｎ ｇｅｎｅｒａｌ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋｓ」）
【非特許文献９】Ｊ．Ｒｅｙ等、「ＲＴＰ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月１５日）
【非特許文献１０】Ｊｏｈｎ Ｌａｚｚａｒｏ「Ｆｒａｍｉｎｇ ＲＴＰ ａｎｄ ＲＴＣＰ Ｐａｃｋｅｔｓ ｏｖｅｒ Ｃｏｎｎｅｃｔｉｏｎ−Ｏｒｉｅｎｔｅｄ Ｔｒａｎｓｐｏｒｔ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月５日）
【非特許文献１１】「Ａ ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ｎｏｎ−Ａｕｄｉｏ Ｄａｔａ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００４年６月７日）
【発明の開示】
【課題を解決するための手段】
【００１７】
（概要）
本発明の以下の実施形態及び態様は、範囲を限定するものではなく、例示的なものであることを意味するシステムと、ツールと、方法とに関連して説明及び図示される。様々な実施形態では、上述の問題のうちの１つ又は複数が低減又は除去され、他の実施形態は、他の利点又は改善の対象となる。
【００１８】
本開示の一部として、インターネットなどのパケット交換ネットワークを介してファックス・データを通信するシステムが提供される。コンピュータ・ネットワーキング及び電気通信では、パケット交換は、現在主要な通信パラダイムであり、パケット交換では、パケット（情報搬送の単位）が、他の多数のノードで共有される可能性のあるデータ・リンクを介してノード間で個々に経路指定される。一般に、本開示は、ファックス・パケットを得るために、第１ストリーミング・プロトコルを使用して設定されるファックス・データのカプセル化を含み、更に、第２ストリーミング・プロトコルを使用するファックス・パケットのカプセル化を含む。第１ストリーミング・プロトコルは、例えば任意のタイプのファックス中継プロトコルでよく、第２ストリーミング・プロトコルは、例えば任意のタイプのリアル・タイム・プロトコルでよい。
【００１９】
ある実施形態によれば、このシステムは、ソース・ファックス・マシンからファックス信号を受信し、ファックス信号からＴ．３８経路を介してＴ．３８ ＵＤＰＴＬパケットを生成し、ＲＴＰ経路を介して、得られるＴ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にカプセル化し、得られるＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをパケット交換ネットワークに送るように適合された送信ゲートウェイを含むことができる。このシステムは、パケット交換ネットワークからＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットを受信し、ＲＴＰ経路を介してＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをカプセル化解除し、Ｔ．３８経路を介して対応するファックス信号を生成し、対応するファックス信号を目標のファックス・マシン又は受信側ファックス・マシン又は所期のファックス・マシンに送るように適合された受信側ゲートウェイも含むことができる。
【００２０】
本開示の一部として、インターネットなどのパケット交換ネットワークを介してファックス・データを送信するゲートウェイが提供される。ある実施形態によれば、送信側ゲートウェイは、ファックス・マシンからファックス信号を受信し、Ｔ．３８ ＵＤＰＴＬパケットを生成するためにファックス信号を処理し、得られるＴ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にＲＴＰ経路でカプセル化し、例えばパケット・インターフェースを介して、ＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをパケット交換ネットワークに送るように適合されたインバウンドＴ．３８経路を含むことができる。
【００２１】
本開示の一部として、インターネットなどのパケット交換ネットワークを介してファックス関連データを送信する機器が提供される。ある実施形態によれば、この機器は、Ｔ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にカプセル化し、得られるＲＴＰパケットをパケット交換ネットワークに送るように適合されたコントローラを含むことができる。ある実施形態によれば、この機器は、パケット交換ネットワークを介してファックス関連データを受信することができる。こうした実施形態によれば、ＲＴＰヘッダと共にカプセル化されたＴ．３８ ＵＤＰＴＬパケットを受信し、ＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットをカプセル化解除するようにコントローラを適合させることもできる。ある実施形態によれば、この装置は、インターネット・アウェア携帯電話、インターネット・アウェア・ファックス、又はインターネット・アウェア・モデムでよい。
【００２２】
本開示の一部として、着信ファックス・データを処理する方法が提供される。ある実施形態によれば、この方法は、Ｔ．３８ ＵＤＰＴＬパケットをＲＴＰヘッダと共にカプセル化することを含むことができる。この方法は、インターネットなどのパケット交換ネットワークにＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットを送ることを更に含むことができる。
【００２３】
本開示の一部として、インターネットなどのパケット交換ネットワークからファックス・データを受信する方法が提供される。ある実施形態によれば、この方法は、パケット交換ネットワークからＲＴＰカプセル化Ｔ．３８ ＵＤＰＴＬパケットを受信し、パケットをインターネット・プロトコル・ヘッダからカプセル化解除し、その後ＵＤＰヘッダからカプセル化解除することを含むことができる。
【００２４】
本開示の一部として、ＲＴＰパケットのペイロードは、Ｔ．３８ ＵＤＰＴＬ型ファックス・データ以外のほぼ任意のタイプのファックス・データを含むことができる。即ち、Ｔ．３８ ＵＤＰＴＬプロトコルに準拠する、ファックス・データ以外のほぼ任意のタイプのファックス・データをＲＴＰヘッダと共にカプセル化することができる。より一般には、ＲＴＰパケットのペイロードは、送信側ゲートウェイ（又は他の装置）内のインバウンドＦＲＰ経路、及び受信側ゲートウェイ（又は他の装置）内のアウトバウンドＦＲＰ経路で処理することのできるファックス中継プロトコル（ＦＲＰ）パケット、ＦＲＰ型ファックス・データを含むことができる。本開示に関連して使用されるＦＲＰ（ファックス中継プロトコル）という用語は、パケット交換ネットワークを介するファックス通信を指し、具体的には、ＦＲＰは、今日知られているほぼ任意のＦＲＰ（例えばＴ．３８ ＵＤＰＴＬ）及び将来考案される任意のＦＲＰを包含することを意味する。ＦＲＰは、既存のＴ．３８ ＵＤＰＴＬの将来の拡張と、機能強化と、改良も含むことができる。本開示に関連して使用されるＦＲＰパケットは、ＦＲＰ１次データ（例えば、Ｔ．３０制御及び／又はファックス・イメージ・データ）と、誤りチェック・データ（例えばシーケンス番号）と、任意選択の誤り訂正データとを含むものとする。ＦＲＰは、ファックス中継情報を転送するための信頼性の高いプロトコルであると想定され、ＲＴＰプロトコル又は標準とは無関係に設計、開発、及び使用を可能にすると想定される。
【００２５】
上述の例示的態様及び実施形態に加えて、図を参照することにより、また以下の詳細な説明を検討することにより、別の態様及び実施形態が明らかとなるであろう。
例示的実施形態が、参照される各図に示される。本明細書で開示される実施形態及び図は、限定的なものではなく例示的なものとみなされるべきものとする。しかし、本発明の編成及び動作方法、並びに目的、特徴、利点に関する開示は、以下の詳細な説明を添付の図面と共に参照することによって最良に理解することができる。
【００２６】
なお、図を簡単にし、見やすくするために、図に示される要素は必ずしも原寸に比例しないことを理解されたい。例えば、図が見やすいように、要素の一部の寸法が他の要素に対して誇張されることがある。更に、適切と考えられる場合に、対応する要素又は類似の要素を示すために、参照番号が各図の間で反復されることがある。
【発明を実施するための最良の形態】
【００２７】
以下の詳細な説明では、開示の完全な理解を与えるために多数の特定の詳細が説明される。しかし、こうした特定の詳細なしに本開示を実施できることを当業者は理解されよう。他の場合には、本開示を不明瞭にしないように、周知の方法と、手順と、構成要素と、回路は、詳細には説明されていない。
【００２８】
別段の指示がない限り、以下の議論から明らかなように、明細書全体を通して、「処理」、「計算」、「決定」などの用語を使用する議論は、コンピューティング・システムのレジスタ及び／又はメモリ内の電子的量などの物理的量として表されるデータを操作し、且つ／又はコンピューティング・システムのメモリ、レジスタ又はその他のそのような情報記憶装置、情報伝送装置、又は情報表示装置内の物理量として同様に表される他のデータに変換するコンピュータ又はコンピューティング・システム、或いは同様の電子コンピューティング装置の動作及び／又はプロセスを指すことを理解されたい。
【００２９】
本開示は、完全なハードウェア実施形態、完全なソフトウェア実施形態、又はハードウェア要素とソフトウェア要素をどちらも含む実施形態の形態を取ることができる。好ましい実施形態では、開示が、限定はしないがファームウェア、常駐ソフトウェア、マイクロコードなどを含むソフトウェアで実装される。
【００３０】
本開示の実施形態は、本明細書に記載のオペレーションを実施する機器を含むことができる。この機器を所望の目的のために特別に構築することができ、又はこの機器は、コンピュータに格納されるコンピュータ・プログラムによって選択的に活動化又は再構成される汎用コンピュータを含むことができる。
【００３１】
更に、この開示は、コンピュータ又は任意の命令実行システムで使用され、又はそれと共に使用されるプログラム・コードを提供するコンピュータ使用可能媒体又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態を取ることができる。この説明では、コンピュータ使用可能媒体又はコンピュータ可読媒体は、命令実行システム、機器、又は装置で使用され、又はそれと共に使用されるプログラムを収容、格納、通信、伝播、又は移送することのできる任意の機器でよい。
【００３２】
プログラム・コードを格納及び／又は実行するのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接的又は間接的に結合された少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードの実際の実行中に使用されるローカル・メモリと、バルク・ストレージと、実行中にコードをバルク・ストレージから取り出さなければならない回数を削減するために少なくとも一部のプログラム・コードの一時的記憶を実現するキャッシュ・メモリとを含むことができる。入出力装置又はＩ／Ｏ装置（限定はしないが、キーボード、ディスプレイ、ポインティング・デバイスなどを含む）を、直接的に、又は介在Ｉ／Ｏコントローラを介してシステムに結合することができる。
【００３３】
ネットワーク・アダプタをシステムに結合することもでき、介在プライベートネットワーク又は公衆ネットワークを介してデータ処理システムを他のデータ処理システム或いはリモート・プリンタ又は記憶装置に結合することが可能となる。モデムと、ケーブル・モデムと、イーサネット（登録商標）・カードは、現在利用可能なタイプのネットワーク・アダプタのほんの数例である。
【００３４】
本明細書で提示されるプロセス及びディスプレイは、何らかの特定のコンピュータ又は他の機器に本質的に関連するものではない。本明細書の教示によるプログラムと共に様々な汎用システムを使用することができ、又は所望の方法を実施するためにより特殊な機器を構築することが好都合であることが判明することがある。様々なこうしたシステムに対する所望の構造が、以下の説明から明らかとなる。更に、本開示の実施形態は何らかの特定のプログラミング言語を参照して説明されるわけではない。本明細書で説明される開示の教示を実装するのに様々なプログラミング言語を使用できることを理解されよう。
【００３５】
パケット損失を最小限に抑え、ゲートウェイで受信されるパケットのリオーダリングを容易にするために、送信側ゲートウェイは、別々のパケット・ストリームで、又は送られる１次パケットと共に同一のストリーム内で、補助冗長パケットをＩＰネットワークに送信する。１次パケットは、データ／情報の一部をそれ自体含むパケットである。補助パケットは、使用される保護方法／プロトコルに応じて、２次パケット、反復パケット、冗長パケット、又はＦＥＣパケットとも呼ばれることがある。例えば、Ｔ．３８／ＵＤＰＴＬでは、冗長パケットは、２次（反復）パケット及び／又はＦＥＣメッセージを含むことができる。ＲＴＰでは、２次パケットは冗長パケットと呼ばれ、ＦＥＣは、具体的には前方誤り訂正パケットを指す。そのような補助データ／情報がない場合、パケットは、１次パケットのみからなり、１次パケットは、ＲＴＰヘッダと共にカプセル化されて提供される。
【００３６】
次に図１を参照すると、例示的な基本的ＦｏＩＰ／ＶｏＩＰシステム（全体的に１００で示す）の略図が示されている。２つのファックス・マシン（１０１及び１０２で示す）と、２つのゲートウェイ（１０３及び１０４で示す）と、ＩＰネットワーク１０７からなる例示的ＦｏＩＰ／ＶｏＩＰシステム１００が、示されている。より一般的には、装置１０１及び１０２のそれぞれは、ＵＤＰＴＬ／ＲＴＰパケットをデータ・ネットワークに／から転送／受信する任意のＩＰ使用可能装置でよい。しかし、話を簡単にするために、以後、装置１０１及び１０２を単にファックス装置又はファックス・マシンと呼ぶ。
【００３７】
伝統的に、ファックス・マシンは、公衆交換電話網（「ＰＳＴＮ」）を介してファックス呼を行うように設計されてきた。そのようなファックス呼を管理する方式と、そのようなファックス呼がＰＳＴＮインフラストラクチャを横断する方式とが、参照により本明細書に組み込まれるＩｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ − Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ（「ＩＴＵ−Ｔ」）ｄｉｖｉｓｉｏｎ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｔ．３０（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｄｏｃｕｍｅｎｔ ｆａｃｓｉｍｉｌｅ ｔｒａｎｓｍｉｓｓｉｏｎ ｉｎ ｇｅｎｅｒａｌ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋｓ」）に定義されている。一般には、ファックス・マシン１０１及び１０２などのファックス・マシンは、例えばＰＳＴＮを介するファックス呼横断を可能にするための変調方式を使用する。例えば、ファックス・マシン１０１又は１０２で開始されたファックス呼は、それぞれゲートウェイ１０３又は１０４までのＰＳＴＮ回線接続１０５又は１０６を横断することができる。しかし、ＦｏＩＰ呼を可能にするためには、即ち、ＩＰネットワーク１０７を介してファックス呼を転送するためには、ファックス・マシンによる信号出力が、ＩＰネットワーク１０７を介する伝送に適したビットストリームに変換されなければならない。この変換は、一方が（通常はＰＳＴＮインターフェースを介して）ファックス端末に接続され、他方がＩＰネットワークに接続される媒体ゲートウェイによって実施される。例えば、ゲートウェイ１０３（更には１０４）は、ＰＳＴＮ接続回線１０５（又は１０６）を介してファックス・マシン１０１に接続され、ファックス・マシン１０１（又は１０２）の信号出力をＩＰネットワーク１０７を介する伝送に適したビットストリームに変換する。ゲートウェイ１０３及び１０４は、対応するビットストリームをＩＰネットワーク１０７に転送するためにＩＰネットワーク１０７に接続される（それぞれ１０９及び１０８で示す）。ＩＰネットワーク１０７はインターネットでよいが、他のタイプのＩＰネットワーク、パケット交換ネットワークも使用することができる。ファックス・マシン１０１及び１０２がＩＰ使用可能である場合、ファックス・マシン１０１及び１０２は、それぞれネットワーク接続１１１及び１１２を介して、直接的にパケットをデータ・ネットワーク１０７に転送し、データ・ネットワーク１０７からパケットを受信することができる。
【００３８】
ゲートウェイ１０３及び１０４などのゲートウェイで実施される変換は、ゲートウェイ内のファックス（中継）受信機による着信サンプリング信号の復調、使用されるファックス中継プロトコル（「ＦＲＰ」）による復調後データのパケット化、及び、宛先（受信側）ゲートウェイに向けてのＩＰネットワークへのＦＲＰパケットの送信を含む。受信側ゲートウェイは通常、受信されたＦＲＰパケットを、ＩＴＵ−Ｔ勧告Ｔ．３０で定義される変調方式に従って再復調するファックス中継送信機を含む。次いで、再復調後信号は、ゲートウェイから、所期の／受信側ファックス・マシンに転送され、そこで再復調後信号が復調され、送信側ファックス・マシンによって送られた元のメッセージ／データが抽出される。
【００３９】
ファックス中継は、ＩＰネットワークを介してエンドツーエンド・ファックス通信を高い信頼性で実施することで知られている。ＦｏＩＰシステムのための通信プロトコルが、参照により本明細書に組み込まれるＩＴＵ−Ｔ勧告Ｔ．３８（「Ｐｒｏｃｅｄｕｒｅｓ ｆｏｒ ｒｅａｌ−ｔｉｍｅ Ｇｒｏｕｐ ３ ｆａｃｓｉｍｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｏｖｅｒ ＩＰ ｎｅｔｗｏｒｋｓ」）に記載されている。一般には、ＩＴＵ−Ｔ Ｔ．３８は、ＦｏＩＰ呼の確立と、Ｇ３タイプ・ファックス呼の異なる信号を転送するパケット・フォーマットとを定義する１組の規則である。
【００４０】
ゲートウェイのＦｏＩＰ部分は、ファックス・マシン１０１及び１０２などの通信する２つのファックス・マシン間で、ファックス・マシンが誤り警報なしにファックス呼／セッションを完了できるような方式で信号を交換することを可能にする。ＦｏＩＰゲートウェイはまた、応答側ファックス・マシンが通信中のゲートウェイからアナログ信号を受信し、「Ｉｎ−Ｍｅｓｓａｇｅ」手順と呼ばれるプロトコル手順を使用することによって応答側ファックス・マシンに転送されたバイナリ情報を抽出することを可能にする。次いで、応答側ファックス・マシンは、発信側ファックス・マシンが意図したように、受信したアナログ信号を解釈することができる。通常、ファックス中継ゲートウェイ（ゲートウェイ１０３及び１０４など）は、ファックス呼の始めから、ファックス呼の間全体にわたって、すべてのタイプのファックス信号を検出し、復調し、再復調する。
【００４１】
装置１１３及び１１４は、インターネット・アウェア装置であり、携帯電話、ファックス装置、又はモデムでよい。インターネット・アウェア装置１１３及び１１４は、例えば互いに、ファックス・マシン１０１又は１０２と、又は他のＩＰファックス使用可能装置（図示せず）とファックス関連データ又は情報を通信又は交換することが可能となるように、ファックス送信機能及び／又は受信機能を有することができる。インターネット・アウェア装置１１３及び１１４は、例えば、それぞれ接続回線１１５及び１１６を介してパケットを転送することができ、且つ／又はＩＰネットワーク１０７からパケットを受信することができる。インターネット・アウェア装置１１３及び１１４は、異なるイメージ・フォーマットでファックス・イメージを転送（及び／又は受信）することができる。
【００４２】
伝統的に、ゲートウェイ１０３及び１０４などのゲートウェイのＶｏＩＰ部分は、８ｋＨｚ以上のサンプリング・レートで入力及び出力音声帯域信号を処理する。ゲートウェイは、インターフェース回路を介してアナログ装置と信号を交換する。図１の各装置が適切な入出力（Ｉ／Ｏ）インターフェースと、反響消去回路と、呼／信号識別回路とを含み、適切な呼確立手順及びその他の前／後処理手順を使用する仮定するが、これらの回路及び手順は本開示の一部ではなく、従って本明細書では参照されない。通常、入力サンプルは、標準変調方式に従ってデジタル・ビットストリームによって変調された正弦波形（搬送波）信号を表す。変調ビットストリームは、ファックス機能、コマンド、応答、イメージ・ビット・マップ、転送されるバイナリ・ファイル、混合ラスタ内容などの有用な情報を含むことができる。
【００４３】
次に図２（従来技術）を参照すると、ファックス通信で使用されるＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰパケットの一般的構造（２００で示す）が、示されている。第１ファックス中継モデルの１つであり、最も使用されるモデルである図２に示されるモデルを、図１に関連して以下で説明する。図１のファックス・マシン１０１からファックス・マシン１０２にファックス通信を送信するために、ファックス・マシン１０１は、ファックス信号（Ｔ．３０制御又はスキャンされたファックス・イメージの変調後データ）を生成し、生成したファックス信号を、（例えば、ＰＳＴＮ回線接続線１０５を介して）互いに通信中の図１のゲートウェイ１０３に転送する。ゲートウェイ１０３は、ゲートウェイ１０３に転送されたファックス・データ／信号をパケット化し、ＩＦＰパケットを形成する。次いで、ゲートウェイ１０３は、各ＩＦＰパケット２０１を（任意選択で冗長性パケット２０２又はＦＥＣメッセージ２０３と共に）ＵＤＰＴＬヘッダ２０４と共にカプセル化する。ゲートウェイ１０３は更に、ＵＤＰＴＬカプセル化パケットをユーザ・データグラム・プロトコル（「ＵＤＰ」）ヘッダ２０５と共にカプセル化する。最終的に、ゲートウェイ１０３は、ＵＤＰカプセル化パケットをＩＰヘッダ２０６と共にカプセル化する。次いで、ゲートウェイ１０３は、得られたデータ・パケット２００を（幾つかの同様にカプセル化されたパケットの中の１つのパケットでよい）、ネットワーク接続１０９を介してＩＰネットワーク１０７に転送する。受信側ゲートウェイ（この例ではゲートウェイ１０４）は、データ・パケット２００を受信し、それをカプセル化解除し、対応するファックス・データ／信号をファックス・マシン１０２に転送することができる。
【００４４】
次に図３（従来技術）を参照すると、ファックス通信で使用されるＩＦＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造が、示されている。先に説明したように、ＲＴＰプロトコルは元来、ＲＴＰペイロードを構成するリアル・タイム媒体を通信するために設計された。しかし、ＲＴＰプロトコルがファックス・データ／信号を（ＩＴＵ−Ｔで最近提案されたようにＩＦＰパケット３０１の形式などで）通信するために使用されたとき、ＩＦＰパケット３０１と、（任意選択）冗長性パケット３０２又はＦＥＣ情報３０３とがＲＴＰペイロードを構成する。図２及び３に示されるモデルは、第１カプセル化ステージが異なる。即ち、ファックス・データ／信号（例えばファックス・データ／信号２０１）をＵＤＰＴＬヘッダ（図２に示される）と共にカプセル化する代わりに、ファックス・データ／信号（例えばファックス・データ／信号３０１）が、ＲＴＰヘッダ３０４（図３に示される）などのＲＴＰヘッダと共にカプセル化される。
【００４５】
図２及び３に示されるモデルの別の違いは、それらの誤り回復データ・フォーマットに関する。即ち、ＵＤＰＴＬは、Ｔ．３８ ＵＤＰＴＬに従って生成された冗長性又はパリティＦＥＣフレームの使用を可能にし、一方ＲＴＰは、ＲＦＣ ２１９８（３０２）で指定される冗長性データ、又はＲＦＣ ２７３３で指定されるＦＥＣデータ（３０３）の使用を可能にする。
【００４６】
プロトコルの一部として、ＲＴＰヘッダ（例えばＲＴＰヘッダ３０４）は、ＲＴＰペイロードに関する情報を含む。例えば、ＲＴＰヘッダ３０４は、ペイロードのソース、サイズなどに関する情報を含む。データ要素３０１から３０４からなるＲＴＰパケットを、ＩＰネットワークを介してそのまま転送することはできない。ＲＴＰパケットの転送を可能にするために、ＲＴＰパケットをＵＤＰヘッダ３０５と共にカプセル化し、得られるパケットを（３０６で示される）ＩＰヘッダと共に更にカプセル化することが必要である。次いで、（３００で示される）得られるパケットをＩＰネットワークを介して転送することができる。
【００４７】
ＩＦＰパケット３０１（並びに任意選択でパケット３０２及び３０３）をＲＴＰヘッダ３０４と共にカプセル化することは、ＩＦＰ−ＲＴＰ関係の点で「直接カプセル化」とみなすことができる。生パケットと考えることのできるＩＦＰパケットがそのままＲＴＰヘッダと共にカプセル化されるからである。ＲＴＰを介するＴ．３８ ＩＦＰパケットの伝送（以後「Ｔ．３８ ＩＦＰ／ＲＴＰ」と呼ぶ）、又は図３に概略を示す直接カプセル化の使用は、以下で詳細に説明するように幾つかの欠点を有する。
【００４８】
次に図４を参照すると、本開示のある実施形態によるＴ．３８ ＵＤＰＴＬ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造が、示されている。図３に示す直接カプセル化とは対照的に、図４は、間接カプセル化方法を示し、この間接カプセル化方法によれば、ＩＦＰパケットがまずＵＤＰＴＬヘッダと共にカプセル化され、それによって標準Ｔ．３８ ＵＤＰＴＬパケット（４０１）が形成される。次いで、図２の要素２０１から２０４などの要素からなると考えることのできるＴ．３８ ＵＤＰＴＬパケット４０１がＲＴＰヘッダ（４０２）と共にカプセル化される。最終的に、ＵＤＰ及びＩＰカプセル化（それぞれ４０３及び４０４）が通常通り実施され、ＩＰネットワークを介して転送可能な新規なタイプのパケット（４００）が形成される。
【００４９】
本開示によれば、ファックスが送信側（ソース）ゲートウェイから受信側（宛先又は目標）ゲートウェイに送信されるときはいつでも、パケット４００のＲＴＰペイロードはＴ．３８ ＵＤＰＴＬパケットであり、リアル・タイム・データ／信号がソース・ゲートウェイから宛先ゲートウェイに送信されるときはいつでも、パケット４００のＲＴＰペイロードは、例えば符号化音声に典型的なものであることに留意されたい。
【００５０】
図５ａと、５ｂと、６と、７とに関して、要素／ユニットと、パケットと、パケットの部分と、プロセスとが、ファックス及びＲＴＰパケットを送信するゲートウェイに関する説明で参照される。しかし、（ＩＰネットワークから）ファックス及びＲＴＰパケットをそれぞれ受信する状況で、同一のゲートウェイに関する説明で参照されることもある。そのような場合、こうした要素／ユニット、パケット、パケットの部分、又はプロセスが、異なる送信側ゲートウェイに属し、又は異なる送信側ゲートウェイから来ると解釈すべきではない。
【００５１】
次に図５ａを参照すると、図２に示されるパケット・モデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットを通信する従来型ゲートウェイが、示されている。ゲートウェイ５００などの典型的な従来型ゲートウェイは、インバウンド及びアウトバウンドのファックス及び音声／オーディオ通信を共に処理するように設計される。ファックス通信に関する説明のために、インバウンド及びアウトバウンドのファックス・データを処理するＦｏＩＰ部分のみを含むゲートウェイ５００を示す。
【００５２】
例示的ゲートウェイ５００のインバウンド・ファックス・データ／情報処理経路（５０１に示される）は、（発信側ファックス・マシンなどの）ソース・ファックス・マシン（など、図示せず）からのファックス・サンプルを受諾し、サンプルを処理し、対応するＦｏＩＰパケットを（Ｔ．３８ ＵＤＰＴＬフォーマットで）転送する。ファックス受信機５０２は、発信側ファックス・マシン（図示せず）からサンプリングしたファックス信号を（例えば、５０６のファックス・サンプルで）受諾し、サンプリングされた信号を復調し、対応するＴ．３０制御及びファックス・データ５０７を生成することができる。Ｔ．３８ ＩＦＰパケッタイザ５０３は、Ｔ．３０制御又はファックス・イメージ・データ（５０７）からＴ．３８ ＩＦＰパケット（５０８）を生成する。Ｔ．３８ ＵＤＰＴＬパケッタイザ５０４は、Ｔ．３８ ＩＦＰパケット（５０８）をカプセル化し、シーケンス番号と、Ｔ．３８ ＩＦＰと、ＵＤＰＴＬ冗長性パケットとを含むＴ．３８ ＵＤＰＴＬパケット（５０９）を形成する。最終的に、パケット・インターフェース５０５は、Ｔ．３８ ＵＤＰＴＬパケット（５０９）をＩＰヘッダと共にカプセル化し、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ５１０を形成し、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ５１０をＩＰネットワーク（図示せず）に転送する。
【００５３】
ファックス・パケット・ストリームをＩＰネットワークに送信するゲートウェイでは、Ｔ．３８ ＵＤＰＴＬパケッタイザ５０４は、新しい１次ＩＦＰパケットごとに（ＵＤＰＴＬヘッダの）シーケンス番号５３５を生成する。任意選択で、Ｔ．３８ ＵＤＰＴＬパケッタイザ５０４は、Ｔ．３８ ＵＤＰＴＬ冗長性フレーム（５３６）又はＦＥＣフレーム（図示せず）を追加することができる。
【００５４】
例示的ゲートウェイ５００のアウトバウンド・ファックス・データ／情報処理部（５１３）は、ＩＰネットワーク（図示せず）からＴ．３８ ＵＤＰＴＬパケット（ＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ ５２０）を受諾し、Ｔ．３８ ＵＤＰＴＬパケットを処理し、対応する再変調後ファックス信号を、ファックス・データが意図される宛先（受信側）ファックス・マシン（図示せず）に転送する任を担う。ＩＰネットワーク（図示せず）を介して到着したＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ ５２０は、パケット・インターフェース５２１で受信され、パケット・インターフェース５２１は、ＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ ５２０を再カプセル化してＴ．３８ ＵＤＰＴＬパケット（５２２）を抽出する。Ｔ．３８ ＵＤＰＴＬデパケッタイザ５２３は、Ｔ．３８ ＵＤＰＴＬパケット５２２からＵＤＰＴＬシーケンス番号と、Ｔ．３８ ＩＦＰパケットと、冗長性又はＦＥＣフレーム（５２４）とを抽出し、それらをＴ．３８ ＵＤＰＴＬ誤り回復モジュール５２５に転送し、Ｔ．３８ ＵＤＰＴＬ誤り回復モジュール５２５は、それらを使用して、ほぼ誤りのないＴ．３８ ＩＦＰパケット（５２６）を再構築する。次いで、ほぼ誤りのないＴ．３８ ＩＦＰパケット５２６がＴ．３８デコーダ５２７で復号化され、Ｔ．３０制御及びファックス・イメージ・データ（５２８）が得られる。Ｔ．３０制御及びファックス・イメージ・データ５２８をＴ．３０／イメージ・データ・バッファ５２９に格納することができる。
【００５５】
ファックス（Ｔ．３８型）パケット・ストリームを受信するゲートウェイは、パケット損失を検出し、パケットが順序が狂ってゲートウェイ５００に到着した場合にパケットをリオーダし、ＩＰネットワークで失われたパケットを回復する。ファックス送信機５３０は、Ｔ．３０／イメージ・データ５２８／５２９を再復調し、ＩＴＵ−Ｔ勧告Ｔ．３０に従ってファックス信号／トーン（Ｆａｘ Ｓａｍｐｌｅｓ Ｏｕｔ ５３１）を受信側／所期のファックス・マシンに転送する。
【００５６】
ファックス中継状態マシン５１１は、ファックス受信機５０２（５１２に示される）及びファックス送信機５３０（５３２に示される）を制御する。状態マシン５１１は、通信ゲートウェイ間でタイムスタンプを転送する必要がない。状態マシン５１１は、受信機５０２及び送信機５３０の現ステータス、ＩＰネットワークを介して交換されるＩＦＰデータの量、Ｔ．３０勧告で定義されるＧ３ファックス・オペレーションの一般的規則を考慮に入れる。ファックス中継状態マシンの基本原理は本発明の主題ではない。
【００５７】
次に図５ｂを参照すると、ＩＰネットワークを介してＲＴＰパケット・ストリームを通信する従来型ゲートウェイのブロック図が、示されている。ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ５５１などのＲＴＰ型パケットをＩＰネットワーク（図示せず）に送信するゲートウェイ（例えばゲートウェイ５６０）は、スピーチ／ボイス・エンコーダ（例えばボイス・エンコーダ５７０）などの媒体ソース・モジュール、ＲＴＰパケッタイザ５７１などのＲＴＰパケッタイザを含み、ボイス・エンコーダ５７０は、ボイスエンコーダ５７０への信号入力を符号化し（Ｓａｍｐｌｅｓ Ｉｎ ５６１）、それから、対応するＲＴＰ１次パケット情報（５７２に示される）を生成する。次いで、ＲＴＰ１次信号がＲＴＰパケッタイザ５７１に転送され（５７３で示される）、ＲＴＰパケッタイザ５７１は、ＲＴＰ１次信号をパケット化して、ヘッダ５７９及び１次パケット５７２を有するＲＴＰパケット５７８をペイロードとして得る。任意選択で、ペイロードは、冗長性データ５７６を含むことができる。パケッタイザ５７１で生成されたヘッダ５７９はとりわけ、対応するＲＴＰペイロード・タイプ識別子と、シーケンス番号と、Ｔｉｍｅ ５７７によって生成され、ＲＴＰパケッタイザ５７１に転送されるタイムスタンプとを含むことができる。冗長性パケットがペイロードに含まれる場合、ヘッダ５７９は、１次パケットに対する各冗長パケットのタイムスタンプ・オフセット及びペイロード・タイプのリストを含むことができる。次いで、ＲＴＰパケット５７９は、パケット・インターフェース５８０に転送され（５７４で示される）、パケット・インターフェース５８０は、ＲＴＰパケットをＵＤＰヘッダと共にカプセル化し、その後で、ＩＰヘッダと共にカプセル化し（５５０で示される）、それによって対応するＶｏＩＰパケット（ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ５５１）を生成し、次いでそれをＩＰネットワーク（図示せず）に送信することができる。
【００５８】
ＲＴＰパケットを受信するゲートウェイは通常、１次パケット並びにタイムスタンプ及び／又はタイムスタンプ・オフセットを使用することにより、パケット損失を検出し、パケットの順序が狂ってゲートウェイに到着した場合にパケットをリオーダし、ネットワークで失われたパケットを回復し、「プレイアウト」バッファを構築し、「プレイアウト」バッファにデータをロードする。「プレイアウト・バッファ」とは、所期のモジュールが「データを再生する」ときにジッタがほぼ回避される方式で、格納された音声／オーディオ関連データがそこから取り出され／フェッチされ、所期のモジュールに送られるバッファを意味する。ゲートウェイは、スピーチ・デコーダ（例えばＶｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ５９８）のような媒体モジュールを使用することによってバッファを再生することができる。ゲートウェイがＲＴＰヘッダ（例えばヘッダ５７９）で指定されるペイロード・タイプを識別した後、異なる媒体タイプ間の切換えは、ゲートウェイによって自律的に行われる。
【００５９】
ＶｏＩＰ Ｐａｃｋｅｔ Ｉｎ（５５２）などのＲＴＰパケットをパケット・インターフェース５８１で受信することができ、パケット・インターフェース５８１は、それをカプセル化解除して、ＲＴＰパケット（例えばＲＴＰパケット５７８）を抽出することができる。ＲＴＰヘッダ（例えばヘッダ５７９）を統計評価のためにＲＴＣＰ Ｓｔａｔｉｓｔｉｃｓ ５９３に転送することができる（５９２）。ＲＴＰパケット全体は、ＲＴＰデパケッタイザ５９１に（５９０で）転送され、ＲＴＰペイロードであるシーケンス番号と、ＲＴＰタイムスタンプと、１次パケットと、冗長性とが抽出され、これらは、パケット損失を検出し、パケットをリオーダし（パケットの順序が狂ってゲートウェイに到着した場合）、ネットワークで失われたパケットを回復するなどのために、ＲＴＰエラー回復５９５で使用される。１次パケット・ペイロードを「プレイアウト」バッファ５９５内に適時に整列し、リモート・ゲートウェイがペイロードを送信した元のシーケンスを復元又は回復するために、ＩＰ Ｔｉｍｅ ５９６は、ＲＴＰタイムスタンプ（５９７で示される）（及び／又はタイムスタンプ・オフセット）を使用することができる。
【００６０】
ゲートウェイ５６０は、ＲＴＰデコーダ・プロセスを使用することによってバッファを再生し、例えばＶｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ５９８などのスピーチ・デコーダでバッファを使用することができる。同期（周期的）ビット・ストリーム（例えば、圧縮オーディオ信号に関する同期ビット・ストリーム）がリモート（送信側）ゲートウェイから受信側ゲートウェイに送信される場合、受信側ゲートウェイのボイス・デコーダ（例えば図５ｂのＶｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ５９８）は、受信側ゲートウェイに到着するデータの平均ビット・レートに近いビット・レートを使用して、プレイアウト・バッファ５９５などのプレイアウト・バッファからデータを読み取る。非同期データ（例えばＤＴＭＦ中継コマンド）が受信側ゲートウェイで受信される場合、受信側ゲートウェイのデコーダは、非同期データと共に受信されたタイムスタンプを使用して、元のタイム・シーケンスを複製し、再生し、再構築し、又は復元する。次いで、デコーダの出力信号を、サンプリングされた信号（Ｓａｍｐｌｅｓ Ｏｕｔ ５６２）の形で所期のマルチメディア（図示せず）に転送することができる。「元のタイム・シーケンス」とは、アウトバウンド・データをＩＰデータ・ネットワークに送信する前に送信側ゲートウェイによってアウトバウンド・データに割り当てられたタイム・シーケンスを意味する。
【００６１】
ゲートウェイ５００などの従来のゲートウェイは通常、ファックス通信とＲＴＰ通信をどちらも可能にするために、図５ｂに示し、図５ｂに関連して説明されるユニットも含むことに留意されたい。そのようなゲートウェイのＦｏＩＰ部分及びＲＴＰ部分が、単に説明がわかりやすいようにする目的で、異なる図（図５ａ及び図５ｂ）に示される。
【００６２】
次に図６を参照すると、図３に示されるパケット・モデルに準拠する構造のパケットを通信する例示的ゲートウェイの略図が、示されている。ゲートウェイ６００のインバウンド経路６０１は、ファックス受信機６０２と、Ｔ．３８ ＩＦＰパケッタイザ６０３と、パケット・インターフェース６０５と、状態マシン６１１とを含み、これらは、それぞれ図５ａのファックス受信機５０２と、Ｔ．３８ ＩＦＰパケッタイザ５０３と、パケット・インターフェース５０５と、状態マシン５１１とほぼ同様に機能する。先に説明したように、ＲＴＰプロトコルの一部として、パケットがＩＰネットワークに送信される前にパケットのそれぞれをタイムスタンプしなければならない。従って、Ｔｉｍｅ ６７７（図５ｂのＴｉｍｅ ５７７とほぼ同様に機能する）は、時間情報を生成し、全ＲＴＰパケットを全体としてタイムスタンプするためにＲＴＰパケッタイザ６４９に転送する（６５０で示される）。ＲＴＰプロトコルの一部として、ＲＴＰパケッタイザ６４９は、ＲＴＰペイロードとしてＲＴＰヘッダ及びＴ．３８ ＩＦＰとＲＴＰ冗長性パケットとからなるＲＴＰパケット（６５１で示される）をパケット・インターフェース６０５に転送する。次いで、パケット・インターフェース６０５は、ＲＴＰパケット（ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ６１０）をＵＤＰ及びＩＰヘッダと共にカプセル化した後に、ＲＴＰパケットをＩＰネットワーク（図示せず）に送信することができる。
【００６３】
ゲートウェイ６００のアウトバウンド経路６１２は通常、異なるタイプの媒体で共通に使用される入出力サンプル及びパケット・インターフェースを含むことができる。Ｔ．３８ユニット６２７、６２９、及び６３０は、図５ａのユニット５２７、５２９、及び５３０とそれぞれほぼ同様に機能する。ＲＴＰユニット６４１、６４３、６４５、及び６４６は、それぞれ図５ｂのユニット５９１、５９３、５９５、及び５９６と同様に通常のＲＴＰパケット処理を実施する。ゲートウェイ６００は、図５ｂのＲＴＰ経路使用可能ユニットも含むことができる（インバウンド経路とアウトバウンド経路の両方）。
【００６４】
（ＲＴＰを介するＴ．３８ ＩＦＰパケットの通信に伴う問題）
（図５ａで例示した）Ｔ．３８ ＩＦＰ／ＵＤＰＴＬプロトコルは、特にＦｏＩＰ通信を可能にするように設計されたので、（図６で例示した）Ｔ．３８ ＩＦＰ／ＲＴＰプロトコルと比較して、信頼性及びファックス通信での相互運用性がずっと低い。Ｔ．３８ ＩＦＰ／ＲＴＰモデルは、以下で説明するように幾つかの欠点を有する。例えば、Ｔ．３８ ＩＦＰパケット・ストリームは、非同期の性質であることを意味し、そのためにＴ．３８ ＩＦＰパケットがソース・ゲートウェイでのファックス中継で処理中に、Ｔ．３８ ＩＦＰパケットはタイムスタンプされない。宛先ゲートウェイでは、ファックス中継はパケットの回復のためにタイムスタンプをシークしていない。即ち、ＲＴＰパケッタイザとは異なり、Ｔ．３８送信機及びＴ．３８受信機は、パケットをタイムスタンプしない。一方、ＲＴＰ型データ・ストリーム、具体的にはＲＦＣ ２１９８に準拠するデータ・ストリームは、同期通信向けに設計され、従ってデータ・パケットのタイムスタンピングは、デコーダでの正確な再生を可能にするためにＲＴＰモデルで主要な役割を果たす。
【００６５】
更に、Ｔ．３８ ＵＤＰＴＬの幾つかの機能、例えばパケット複製（受信側ゲートウェイで紛失パケットの回復を可能にするために、パケットをＩＰネットワークに送信するゲートウェイによって適用される機能）と、パケット・リオーダを可能にすることは、以下で詳細に説明するように、ＲＴＰプロトコルとの競合のためにＴ．３８ ＩＦＰ／ＲＴＰ（図６）には適用することができない。
【００６６】
通常のＴ．３８ ＩＦＰパケッタイザは、グループでのＩＦＰパケットの伝送を可能にする。任意のグループ内のパケットを同時に生成することができる。しかし、ＲＴＰプロトコルの一部として、あらゆるパケットが、更に処理され、ＩＰネットワークに送信される前に、Ｔｉｍｅ ６７７によってタイムスタンプされる（例えば、図６の６４７で示される）。従って、図６で例示されるＴ．３８ ＩＦＰ／ＲＴＰは、伝送時間が同一の同時に送信されたＩＦＰパケットのタイムスタンピングを必然的に伴う。しかし、ＲＴＰプロトコルと、グループ内のパケットを同時にタイムスタンプすることの間に矛盾が存在する。ＲＴＰプロトコルによれば、所与のタイムスタンプに割り当てることのできるパケットは１つだけであるからである。従って、正当なＴ．３８ ＩＦＰの機能であるパケットの同時伝送が、ＲＴＰに関する矛盾を引き起こす可能性があり、その結果、パケット損失の範囲の如何に関わらず、ＲＴＰを介して転送されたＴ．３８ ＩＦＲパケットを正しく解釈することができなくなる。
【００６７】
図６に戻ると、Ｔ．３８ ＩＦＰパケッタイザ６０３がＴ．３８ ＩＦＰパケットを適時に待ち行列化及び配布する（通常のＴ．３８ ＩＦＰパケッタイザ５０３に比べて）追加の機能を有する場合、幾つかのＴ．３８ ＩＦＰパケットが同一のタイムスタンプを有するというファックス・パケット・バースト／グループの問題を解決することができる。パケット・バースト問題の他の解決策は、Ｔ．３８パケット化（６０３）のステージでタイムスタンプ（６４７）を適用し、後にこうしたスタンプを、Ｔｉｍｅ ６７７からの通常のタイムスタンプの代わりにＲＴＰパケッタイザ（６４９）で使用することである。この解決策は、追加の遅延を導入しないので、適時にＩＦＰパケットを配布することよりも良いが、通常のＴ．３８ ＩＦＰパケッタイザ５０３に対してＴ．３８ ＩＦＰパケッタイザ（６０３）、及び通常のＲＴＰパケッタイザ５７１に対してＲＴＰパケッタイザ（６４９）という２つのモジュールの変更を必要とする。
【００６８】
（パケット・ストリーム：ＲＴＰオーディオ・パケットに対するＴ．３８ ＩＦＰパケット）
ファックス中継パケット（Ｔ．３８ ＩＦＰパケット）ストリームとオーディオ・パケット（ＲＴＰオーディオ・パケット）ストリームとの違いの幾つかを以下で説明する。ＲＴＰオーディオ・パケット・ストリームは通常、完全２重及び同期式（大部分は周期的）である。即ち、通信に関係する２つのゲートウェイのそれぞれが、ＩＰネットワークにオーディオ関連パケットを周期的に転送する。宛先ゲートウェイとして働くゲートウェイは、ソース・ゲートウェイとして働くゲートウェイに対して同期式にオーディオ・パケットを復号化（再生）する。即ち、オーディオ関連データ・ストリームは、両方の（送信側及び受信側）ゲートウェイによってほぼ同一のビット・レートで処理される。オーディオ・ゲートウェイの１つの目標は、エンドツーエンドでひずみ及びジッタが可能な限り最小限に抑えられたオーディオ信号を送達することであるからである。
【００６９】
一方、Ｔ．３８ ＩＦＰパケット・ストリームは一般に、擬似ランダム・パケット送信／受信間隔の半２重及び非同期データ・ストリームである。Ｔ．３８ ＩＦＰパケット・ストリームは、（時折、同期データについて）パケットのバースト（グループ）からなる可能性があり、パケットのバーストは、送信側ゲートウェイによって同時に生成されることがあり、或いはＴ．３８ ＩＦＰパケット・ストリームは、連続するパケット間に長い時間ギャップ又はウィンドウを有することがある。
【００７０】
（Ｔ．３８ ＵＤＰＴＬでのシーケンス番号及びＲＦＣ ３５５０）
Ｔ．３８ ＵＤＰＴＬでは、ファックス中継セッションの最初に送られる初期ＦｏＩＰパケットのシーケンス番号が、ゼロであるべきであり、ファックス復調器から出力される新しいＩＦＰ１次パケットごとに、連続する送信パケットのシーケンス番号が１だけ増分される。しかし、Ｔ．３８ ＩＦＰパケットが複製される場合、複製されたパケットのシーケンス番号は、先に送られたパケットに対して増分されず、複製されたパケットは、そのパケットが再現する元のパケットと同一のシーケンス番号を有する。一般には、ＵＤＰＴＬパケット・シーケンス番号は、到着ストリーム中の正しいパケット・シーケンスを識別するのに使用される。タイムスタンプ及び時間オフセットは不要であり、Ｔ．３８ ＵＤＰＴＬプロトコルでも使用されない。従って、ファックス中継変調器は、（Ｔ．３８パケットを送信するゲートウェイ内の）リモート・ファックス復調器で発生したファックス信号のタイム・シーケンスを復元する必要がない。Ｔ．３８パケットを受信するゲートウェイは、リモート・ゲートウェイから受信したＴ．３０制御メッセージ／コマンドを拒絶又は置換することが可能である。Ｔ．３８パケットを受信するゲートウェイ内のファックス中継変調器は、それに接続されたファックス・マシンに、元のファックス・メッセージがＩＰネットワークを介して転送されたビット・レートとは異なるビット・レートで（例えばＰＳＴＮを介して）データ／信号を送信することができる。Ｔ．３８モジュールの出力信号は、ファックス中継送信機がＩＰネットワークを介して首尾よくファクシミリ通信するための主要件であるファクシミリ伝送に関するＴ．３０勧告で定義された手順に準拠すべきである。送信側ゲートウェイから受信されたＴ．３８ ＩＦＰパケットの正しいシーケンスは、タイミング・シーケンスに勝る重要な意味を持つ。ゲートウェイがＧ３ファックス通信にとって受け入れられる信号シーケンスを送信した場合であっても、ゲートウェイが変調のためのバイナリ・データを失った場合、ファックス・セッションが失敗する可能性がある。
【００７１】
Ｔ．３８ ＵＤＰＴＬとは対照的に、且つＲＦＣ ３５５０に準拠して、第１ＲＴＰパケットに割り当てられた初期シーケンス番号は、ランダムであるべきであり、ＲＴＰシーケンス番号は、送信側ゲートウェイによってＩＰネットワークに転送される次のＲＴＰデータ・パケットごとに１だけ増分されるべきである。シーケンス番号を増分することは、ペイロード（媒体）タイプとは無関係に実施される。シーケンス番号は、パケット損失を検出し、パケット・シーケンスを復元するために受信側ゲートウェイで使用される。しかし、パケット損失を検出及び回復することは、シーケンス番号だけを使用することでは行うことができない。例えば、ゲートウェイは、（異なるペイロード・タイプを有する）圧縮オーディオ及びＤＴＭＦストリームをＩＰネットワークに送信することができる。ＤＴＭＦ中継パケットは、ネットワーク内で失われる可能性があるのに対して、圧縮オーディオ・ストリームに関するあらゆるパケットは首尾よくその宛先（例えば受信側ゲートウェイ）に到達する。受信側ゲートウェイは、パケット損失を検出することができるが、パケット損失を受ける媒体タイプ・ストリームの識別、及び誤り回復の目的ではパケット損失を検出することができず、ゲートウェイは、区間タイムスタンプを必要とする。パケット損失に関連する統計は、受信されたシーケンス番号に基づき、パケット損失に関連する統計が必要とされる所がどこであっても、標準ＲＴＣＰプロトコルを使用してレポートすることができる。
【００７２】
（タイムスタンプ）
ファックス中継ゲートウェイは、送信されたＦｏＩＰパケットをタイムスタンプせず、ＦｏＩＰパケットを受信したとき、ファックス信号を所期のファックス・マシンに送信するためにタイムスタンプを必要ともしない。Ｔ．３８プロトコルとは対照的に、あらゆる１次ＲＴＰパケットは、ＲＦＣ ３５５０に従うタイムスタンプを有し、あらゆる冗長パケットは、ＲＦＣ ２１９８に従うタイムスタンプ・オフセットを有する。タイムスタンプ及びタイムスタンプ・オフセットは、誤り回復及び信号フローの再構築のためにＲＴＰ受信機によって使用され、ＲＴＰ受信機がそのプレイアウト・バッファを正しく再生することを可能にする。ゲートウェイ間の同期データ転送中のパケット損失の場合、パケットが固定の持続時間を有すると仮定して、特定のペイロード・タイプに関係する紛失パケットの数をタイムスタンプから導出することができる。しかし、非同期データ転送中に失われたパケット、又は可変フレーム持続期間に関しては、タイムスタンプは役に立たない。非同期データ転送中の紛失パケットの問題を克服するために、受信側ゲートウェイは、ＲＦＣ ３５５０及びＲＦＣ ２１９８プロトコルで説明され、又は提案されているものよりもずっと複雑な媒体特性、媒体プロトコル機能強化又は技法を使用する。非同期ＲＴＰ転送の一例は、ＤＴＭＦと、電話と、単純なモデム信号用に設計されたＲＦＣ ２８３３仕様を有するＤＴＭＦ中継に関連する。しかし、ＡＶＴフォーラムは、ファックス中継データ転送専用のＲＦＣをまだ提案しておらず、Ｔ．３８ ＵＤＰＴＬよりずっと良いＲＦＣを予期することができない。
【００７３】
（Ｔ．３８ ＩＦＰパケット複製）
Ｔ．３８ ＩＦＰ／ＵＤＰＴＬでは、ファックス・パケットの複製は、ファックス中継の信頼性を高める。従って、非常に重要なパケットに関して、例えばＴ．３０ ＮＤＩＣＡＴＯＲ、Ｔ．３０ ＤＡＴＡ ＨＤＬＣ−ＯＫ／ＢＡＤ、Ｔ．３０ ＤＡＴＡ ＳＩＧＮＡＬ−ＥＮＤなどに関係又は関連するパケットに関して複製を実施することができる。
【００７４】
Ｔ．３８ ＩＦＰ／ＵＤＰＴＬプロトコルとは対照的に、Ｔ．３８ ＩＦＰ／ＲＴＰゲートウェイは、ＲＴＰシーケンス番号を増分せずにパケットを送信することができない。更に、増分されたＲＴＰシーケンス番号を有するＩＦＰパケットの複製を使用することができない。Ｔ．３８受信機は、反復されるＩＦＰデータを新しいバイナリ・データとみなし、その結果、Ｔ．３８ファックス変調器は、例えばＰＳＴＮ回線によってゲートウェイに結合されたファックス・マシンに、無効なバイナリ情報を送信することになる。
【００７５】
（同時に複数のＴ．３８ ＩＦＰパケットの生成）
ＲＴＰプロトコルとは対照的に、Ｔ．３８パケット・ストリームは、ほぼ同時に生成されたパケットのシーケンスを含むことができる。この１つの理由は、関連する制御情報を使用することによって受信側ゲートウェイが適時にインバウンド・データ・ストリームを処理することを可能にするために、制御情報とデータを共に含むファックス信号をほぼ同時に送信及び受信しなければならないことである。例えば、Ｔ．３０ ＤＡＴＡ ＨＤＬＣ−ＤＡＴＡ及びＨＤＬＣ−ＯＫ／ＢＡＤに関係するパケット、又はそれらから導出されるパケットをほぼ同時に生成及び通信することができる。同様に、Ｔ．３０ ＤＡＴＡ ＳＩＧＮＡＬ−ＥＮＤ及びＴ．３０ ＩＮＤＩＣＡＴＯＲ ＮＯ−ＳＩＧＮＡＬに関係するパケット、又はそれらから導出されるパケットをほぼ同時に生成及び通信することができる。Ｔ．３８パケット・ストリームがほぼ同時に生成されたパケットのシーケンスを含むことができる別の理由は、宛先（受信側）ゲートウェイが処理することのできるパケット化間隔と、送出側（送信側）ゲートウェイの作業フレーム持続期間との間に存在する差である。例えば、宛先ゲートウェイの最大パケット化間隔が１０ミリ秒（ｍｓ）であるが、ソース・ゲートウェイの最小フレーム持続期間が２０ｍｓである場合、送信側ゲートウェイは、２つ以上のパケットからなるバーストとしてＴ．３８型データ・ストリームを送信する。ＩＰ使用可能ファックス・マシンは、パケット・バーストも送信することができる。非ＩＰファックス・マシンとは異なり、ＩＰ使用可能ファックス・マシンは、信号復調を実施又は使用せず、その結果ＩＰファックス・マシンは、経時的なコマンド又はデータの配布を処理する必要がないからである。その代わりに、ＩＰ使用可能ファックス・マシンは、単一のパケット・キューを処理する。同一のタイムスタンプでＲＴＰを介して送信されたＴ．３８ ＩＦＰパケットは、プレイアウト・バッファの再構築の段階でＲＴＰ受信機によって拒絶される可能性がある。従って、ＲＴＰを介して中継される通常のＴ．３８セッションは、パケット損失がない場合であっても失敗する可能性がある。
【００７６】
（冗長性レベル）
Ｔ．３８ ＵＤＰＴＬファックス中継セッションの間、ＦｏＩＰ情報の冗長性レベルは、例えばＴ．３０制御コマンドを変更する可能性があり、データが、ファックス・イメージ・データの冗長性レベルよりも高い冗長性レベルで転送される可能性がある。これは、Ｔ．３０制御信号を中継するときに信頼性を高めるのに有用である。ＲＴＰを介して転送されるＴ．３８ ＩＦＰの場合、冗長性レベルの変化は、ＲＴＰパケット化の段階で（転送されるデータのタイプを理解するために）Ｔ．３８ ＩＦＰ復号化を必要とするので問題である。
【００７７】
（Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰ実装問題）
ゲートウェイ・レベルでは、Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰの実装に関連する主な難点は、２つの比較的複雑なモジュールであるＴ．３８モジュールとＲＴＰモジュールを、それらの性能／機能の適合を含めて、適合させ、又は変更する必要があることである。適合は、パケット生成、パケット受信、紛失パケットの回復、及び「順序が狂って」到着したパケットのリオーダを含むすべてのレベルのパケット処理で必要となる可能性がある。ある場合には、ファックス受信機／送信機及びＴ．３８ ＩＦＰエンコーダ／デコーダがＲＴＰ／ＵＤＰＴＬパケッタイザ／デパケッタイザとは異なるハードウェア要素（例えばＤＳＰ）上に物理的に実装される幾つかのケースでは（後者は、例えばＰＣ上に実装することができる）、Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰを実装するのに必要な範囲で「Ｔ．３８経路」を変更することが可能である。ＩＰ使用可能電話及びＩＰ使用可能ファックス・マシンでは、Ｔ．３８ ＩＦＰ ｏｖｅｒ ＲＴＰ手法はやはり非常に問題がある。ＩＰ使用可能ファックス・マシンは、タイムスタンプを使用せずにＴ．３８ ＵＤＰＴＬパケットを送信／受信するからであり、そのような装置は、モデムのような信号処理を実施することができないからである。
【００７８】
（代替プロトコル）
ＲＴＰを介して非オーディオ・データを転送することに関連する問題に対するその他の解決策を提供することを試みて、ＡＶＴ Ｉｎｔｅｒｎａｔｉｏｎａｌフォーラムは、ＲＦＣ ３５５０及びＲＦＣ ２１９８プロトコルに対する代替として３つのプロトコルを考案した。（１）ＦＥＣデータ（既に先に述べた）を使用する方式を指定するＲＦＣ ２７３３、（２）例えば、参照により本明細書にその内容全体が組み込まれるＪ．Ｒｅｙ等の「ＲＴＰ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月１５日）に記載されているＲＴＰ再送信ペイロード・フォーマット、（３）例えば、参照により本明細書にその内容全体が組み込まれるＪｏｈｎ Ｌａｚｚａｒｏ（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００５年９月５日）「Ｆｒａｍｉｎｇ ＲＴＰ ａｎｄ ＲＴＣＰ Ｐａｃｋｅｔｓ ｏｖｅｒ Ｃｏｎｎｅｃｔｉｏｎ−Ｏｒｉｅｎｔｅｄ Ｔｒａｎｓｐｏｒｔ」に記載されているＲＴＰ ｏｖｅｒ ＴＣＰ。しかし、これらのプロトコルもまた、ＲＦＣ ３５５０及びＲＦＣ ２１９８と比較して使用するのが複雑であり、更には、これらの３つのプロトコルの何れか１つを使用するときに、ファックス中継及びＲＴＰモジュールを構造的且つ機能的に互いに適合させるのがより難しいという点で問題がある。
【００７９】
ＲＦＣ ２１９８の冗長性方式を使用することによって非オーディオ・データ用の新しいフォーマットを定義する試みが、Ｓａｔｉｓｈ Ｍｕｎｄｒａ（Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ， Ｉｎｃ．）によってなされた。この試みは、例えば、参照により本明細書にその内容全体が組み込まれる「Ａ ＲＴＰ Ｐａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ｎｏｎ−Ａｕｄｉｏ Ｄａｔａ」（Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ、２００４年６月７日）に記載されている。ＩＦＰ／ＲＴＰファックス中継に関する問題は、このプロトコルがＴ．３８及びＲＴＰモジュールにかなりの変更を必要とすることである。
【００８０】
次に図７を参照すると、図４に示すモデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットと、本開示のある実施形態によるＲＴＰパケットとを通信するゲートウェイのブロック図が示されている。ゲートウェイ７００のインバウンド経路７０１は、ゲートウェイ７００のファックス・インバウンド経路を形成するユニット７０２、７０３、７０４、及び７７１を含むことができ、ユニット７０２、７０３、及び７０４は一般に、図５ａのゲートウェイ５００内のそれぞれユニット５０２、５０３、及び５０４とほぼ同様に機能する。ゲートウェイ７００のインバウンド経路７０１はまた、ゲートウェイ７００のＲＴＰインバウンド経路を形成するユニット７７０及び７７１も含み、一般に、図５ｂのゲートウェイ５６０内のそれぞれユニット５７０及び５７１とほぼ同様に機能する。ファックス・インバウンド経路とＲＴＰインバウンド経路の両方でユニット７７１（ＲＴＰパケッタイザ７７１）を使用することができ（同時にではない）、ファックス中継状態マシン７１１は一般に、図５ａの状態マシン５１１及び図６の状態マシン６１１とほぼ同様に機能する。ＲＴＰ通信では、Ｔｉｍｅ ７７７は一般に、図５ｂのＴｉｍｅ ５７７とほぼ同様に機能する。ファックス受信モジュールであるファックス受信機７０２は一般に、図５ａのゲートウェイ５００内のファックス受信機５０２とほぼ同様に機能する。即ち、ファックス受信機７０２は、アナログ・ファックス伝送（この例ではＦａｘ Ｓａｍｐｌｅｓ Ｉｎ ７６１）をファックス・データ・セット（この例では、Ｔ．３０制御及びファックス・イメージ・データ７６４）に変換することができる。ＦｏＩＰパケットでは、パケット・インターフェース７０５は一般に、図５ａのゲートウェイ５００内のパケット・インターフェース５０５とほぼ同様に機能するのに対して、ＲＴＰパケットパケット・インターフェース７０５は一般に、図５ｂのゲートウェイ５６０内のパケット・インターフェース５８０とほぼ同様に機能する。Ｔ．３８ ＩＦＰパケッタイザ７０３と、Ｔ．３８ ＵＤＰＴＬパケッタイザ７０４と、ＲＴＰパケッタイザ７７１は、ＩＰ通信モジュールを形成することができ、ＩＰ通信モジュールはまず、第１ストリーミング・プロトコル（この例ではＴ．３８ ＵＤＰＴＬ）を使用してファックス・データ・セット（７６４で示される）をカプセル化して、ファックス・パケット（７６６で示される）を得、次いで、第２ストリーミング・プロトコル（この例ではＲＴＰ）を使用して、得られたカプセル化ファックス・パケット（７６６で示される）を更にカプセル化する。
【００８１】
ゲートウェイ７００のアウトバウンド経路７１２は、ユニット７２３、７２５、７２７、７２９、及び７３０を含むことができ、ユニット７２３、７２５、７２７、７２９、及び７３０は、ゲートウェイ７００のファックス・アウトバウンド経路を形成し、一般に図５ａのゲートウェイ５００内のそれぞれユニット５２３、５２５、５２７、５２９、及び５３０とほぼ同様に機能する。ゲートウェイ７００のアウトバウンド経路７１２はまた、ユニット７９１、７９３、７９５、及び７９８も含み、ユニット７９１、７９３、７９５、及び７９８は、ゲートウェイ７００のＲＴＰアウトバウンド経路を形成し、一般に図５ｂのゲートウェイ５６０内のそれぞれユニット５９１、５９３、５９５、５９８とほぼ同様に機能する。ゲートウェイ７００のアウトバウンド経路７１２はまた、ＩＰ Ｔｉｍｅ（図示せず）も含み、ＩＰ Ｔｉｍｅは、図５ｂのゲートウェイ５６０内のＩＰ Ｔｉｍｅ ５９６（又は図６のゲートウェイ６００内のＩＰ Ｔｉｍｅ６４６）とほぼ同様に機能する。
【００８２】
ＦｏＩＰパケットでは、パケット・インターフェース７２１は一般に、図５ａのゲートウェイ５００内のパケット・インターフェース５２１とほぼ同様に機能する。ＲＴＰパケットでは、パケット・インターフェース７２１は一般に、図５ｂのゲートウェイ５６０内のパケット・インターフェース５８１とほぼ同様に機能する。ファックス送信機７３０は一般に、図５ａのゲートウェイ５００内のファックス送信機５３０とほぼ同様に機能する。
【００８３】
図７のゲートウェイ７００のインバウンド経路７０１に関して、ゲートウェイ７００に対する入力ソース（７６０）は、ファックス信号（Ｆａｘ Ｓａｍｐｌｅｓ Ｉｎ ７６１）又は音声（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ７６２）でよく、それらは、ファックス・マシン、マルチメディア装置（図示せず）などから発生又は転送させることができる。本開示は、ＲＴＰを介してファックス通信を通信すると共に、ＲＴＰ関連データ／情報が従来の方式で通信される新規な方式を開示する。本開示の一部として、ゲートウェイ７００が、ファックス・データ、又はＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７１０などのファックス関連データ／情報をＩＰネットワーク（図示せず）に送信するときはいつでも、ＲＴＰパケットのペイロードは、例えばＲＴＰペイロードが基本的Ｔ．３８ ＩＦＰパケットである図３及び６に示される方法とは対照的に、関連するＴ．３８ ＵＤＰＴＬパケット７６３全体である。即ち、Ｔ．３０制御／ファックス・イメージ・データ７６４が、従来通りＴ．３８ ＩＦＰパケッタイザ７０３で処理され、対応する標準Ｔ．３８ ＩＦＰパケット（７６５）が生成される。次いで、得られるＴ．３８ ＩＦＰパケットが、Ｔ．３８ ＵＤＰＴＬパケッタイザ７０４で処理され、対応するＴ．３８ ＵＤＰＴＬパケット（７６６）が生成される。
【００８４】
図６に示すようにＴ．３８ ＩＦＰパケットをタイムスタンプすることは（６４７）、Ｔ．３８ ＵＤＰＴＬパケットの保全性又は従来のフォーマットを破る。従って、そのようなタイムスタンピングを避けることは、従来のＴ．３８ ＵＤＰＴＬフォーマットの保全性、従ってＴ．３８ ＵＤＰＴＬフォーマットに関連する元の利点を維持する。次いで、Ｔ．３８ ＵＤＰＴＬパケット全体（７６６）がＲＴＰパケッタイザ７７１によってＲＴＰペイロードとしてＲＴＰカプセル化される。ＲＴＰカプセル化は、１つのタイムスタンピング・プロセスだけを含む。即ち、ＲＴＰパケット全体だけが、ＲＴＰパケットのペイロードとしてのＲＴＰパケット内のＴ．３８ ＵＤＰＴＬパケットと共にタイムスタンプされる（図７の７５０として示される）。ＲＴＰパケッタイザ７７１によってＲＴＰヘッダと共にカプセル化されたファックス中継（Ｔ．３８ ＵＤＰＴＬ）パケットは、ＲＦＣ ３５５０に従ってフォーマットされる。ファックス中継パケットをパケット・インターフェース７０５に送信する前に、異なる媒体データについて共通の任意選択の暗号化をファックス中継パケットに対して使用することができる。ＲＦＣ ２１９８によるＲＴＰ冗長性又はＲＦＣ ２７３３によるＲＴＰ ＦＥＣはファックス中継データ通信中に使用されない（必要でもない）。ファックス中継データを保護するのに必要な誤り回復データが、通常のファックス通信と同様にＴ．３８ ＵＤＰＴＬを介して転送されるからである。
【００８５】
ゲートウェイ７００のアウトバウンド経路７１２に関して、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７１０などのＦｏＩＰパケットがパケット・インターフェース７２１で受信されるときはいつでも、パケット・インターフェース７２１は、ＦｏＩＰパケットのＩＰ及びＵＤＰヘッダからＦｏＩＰパケットをカプセル化解除し、この場合、ＲＴＰパケットのペイロードを伴うＲＴＰパケットと、ＦｏＩＰパケットとを（Ｔ．３８ ＵＤＰＴＬフォーマットの形式で）抽出する。ＲＴＰパケットのヘッダを、前述のようにＲＴＰプロトコルの従来の特徴である統計評価のために、ＲＴＣＰ７９３で使用することができる。次いで、Ｔ．３８ ＵＤＰＴＬパケットを、Ｔ．３８ ＵＤＰＴＬデパケッタイザ７２３と、Ｔ．３８ ＵＤＰＴＬ誤り回復７２５と、Ｔ．３８デコーダ７２７と、Ｔ．３０／イメージ・データ・バッファ７２９と、ファックス送信機７３０とを含むことのできるＴ．３８経路で従来通り処理することができる。
【００８６】
音声が通信されるときはいつでも、音声は、ゲートウェイ７００で従来の方式で処理される。即ち、音声に関連する信号（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ７６２）がボイス・エンコーダ７７０で符号化され、符号化データがＲＴＰパケッタイザ７７１に転送され（７６８）、ＲＴＰパケッタイザ７７１は、（図７ではなく）図５ｂに示すのと同様に、この時にはＲＴＰヘッダと、１次パケット及び冗長性パケットを含むＲＴＰペイロードとからなるＲＴＰパケット（７５１）をパケット・インターフェース７０５に転送する。次いで、パケット・インターフェース７０５は、ＲＴＰパケット（ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７６７）をＵＤＰヘッダ及びＩＰヘッダと共にカプセル化した後に、ＲＴＰパケットを、ＩＰネットワーク（図示せず）に送信することができ、所期の受信側ゲートウェイに送信することができる。
【００８７】
ゲートウェイ７００のアウトバウンド経路７１２に関して、ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ７６７などのＶｏＩＰパケットがパケット・インターフェース７２１で受信されるときはいつでも、パケット・インターフェース７２１は、ＶｏＩＰパケットのＩＰヘッダ及びＵＤＰヘッダからＶｏＩＰパケットをカプセル化解除し、この場合は（標準ＲＴＰフォーマットの）ＶｏＩＰパケットであるＲＴＰパケットをそのＲＴＰペイロードと共に抽出する。ＲＴＣＰ ７９３は、統計評価のためにＲＴＰパケットのヘッダを使用することができる。次いで、ＲＴＰデパケッタイザ７９１と、誤り回復及びＲＴＰプレイアウト・バッファ７９５と、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ（Ｐｌａｙ）７９８とを含むことのできる従来のＲＴＰ経路でＲＴＰパケットを通常通り処理することができる。
【００８８】
ＲＴＰデパケッタイザ７９１によるＲＴＰパケット化解除の結果として、送信されるＲＴＰシーケンス番号、ＲＴＰタイムスタンプ、及び／又はタイムスタンプ・オフセット、１次（ＶｏＩＰ）パケット、並びに冗長性データ又はパケットが抽出され（例えば図５ｂの５９４として示される）、（誤り回復及び）ＲＴＰプレイアウト・バッファ７９５で使用されて、パケット・シーケンスが補正され、又は紛失パケットが回復され、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ７９８での使用のために一時的にパケットが格納される。
【００８９】
図７のゲートウェイは、従来技術のゲートウェイに勝る幾つかの利点を有する。図５ａのゲートウェイ５００に示されるファックス（インバウンド及びアウトバウンド）経路などのファックス経路と、図５ｂのゲートウェイ５６０に示されるＲＴＰ（インバウンド及びアウトバウンド）経路などのＲＴＰ経路の両方を含むゲートウェイに関して、ファックス経路及びＲＴＰ経路は、互いに独立に動作する。ファックス経路及びＲＴＰ経路は、ＲＴＰペイロード（ＲＴＰパケットであってもＴ．３８ ＵＤＰＴＬパケットであっても）が受信側ゲートウェイで識別されると、他の経路（それぞれＴ．３８ ＵＤＰＴＬ又はＲＴＰ）の要件及び機能の如何に関わらず、対応する経路（それぞれＲＴＰ又はＴ．３８ ＵＤＰＴＬ）でペイロードが処理されるという意味で互いに独立に動作する。従って、各タイプの経路の従来の利点が維持される。更に、ファックス通信が図７のゲートウェイ７００などのゲートウェイで実装される場合、ファックス通信は、自律的媒体（ペイロード・タイプ）切換え、セキュア転送、統計評価などのＲＴＰ経路の従来の利点も亨受する。
【００９０】
図６の従来のゲートウェイ６００に関して、図７のゲートウェイ７００は、Ｔ．３８ ＩＦＰの変更或いはＴ．３８ ＩＦＰパケッタイザとＲＴＰパケッタイザの両方の変更を必然的に伴う図６の６４７及び６５０で示されるタイムスタンピング・プロセスを使用するのではなく、通常のＲＴＰで一般に使用される図７の７５０に示されるタイムスタンピング・プロセスを使用する。受信されたＴ．３８ ＵＤＰＴＬ／ＲＴＰパケットのＲＴＰヘッダは、ＲＴＣＰ ｓｔａｔｉｓｔｉｃｓ（７９３）のためだけに使用され、Ｔ．３８ ＵＤＰＴＬデパケッタイザ（７２３）への入力では省略される。パケット損失の保護又は回復のためのＵＤＰＴＬシーケンス番号、冗長性、又はＦＥＣ処理は一般に、通常のＴ．３８ ＵＤＰＴＬ経路で実施される。
【００９１】
更に、ＵＤＰＴＬデータをＲＴＰヘッダと共にカプセル化する結果、ＲＴＰヘッダがＩＦＰデータをカプセル化するときのＲＴＰヘッダのサイズと比較して、ＲＴＰヘッダが小さくなる。一般に、使用される冗長性が多くなるほど、ヘッダ・サイズがより節約される。ＩＦＰ／ＲＴＰでは、ＲＦＣ ２１９８で指定されるように、ＲＴＰヘッダ長は冗長性レベルに比例するのに対して、ＵＤＰＴＬ／ＲＴＰでは、ＲＴＰヘッダは、ＲＦＣ ３５５０で定義される固定のサイズを有する。
【００９２】
図７の新規なゲートウェイに関して、Ｔ．３８ ＵＤＰＴＬ標準及びＲＴＰプロトコルの点で変更は不要である。本明細書で開示される新規なプロトコル（例えばＴ．３８ ＵＤＰＴＬ ｏｖｅｒ ＲＴＰ又はＴ．３８ ＵＤＰＴＬ／ＲＴＰ）は、Ｔ．３８ ＵＤＰＴＬパケットを図７の７０５として示されるパケット・インターフェースに直接送信するのではなく、図７の７７１として示されるＲＴＰパケッタイザへのＴ．３８ ＵＤＰＴＬパケットの比較的単純なリダイレクトを使用する。Ｔ．３８／ＵＤＰＴＬ／ＲＴＰ型パケットがパケット・インターフェース７２１で受信されるとき、新規なゲートウェイ（図７のゲートウェイ７００）は、図６のＲＴＰデパケッタイザ６４１などのＲＴＰデパケッタイザにＲＴＰパケット全体をリダイレクトするのではなく、ＲＴＰパケット・ペイロード（１次ＲＴＰ）を図７のＴ．３８ ＵＤＰＴＬデパケッタイザ７２３などのＴ．３８ ＵＤＦＴＬデパケッタイザにリダイレクトする。
【００９３】
図７のゲートウェイ７００の新規な機能を、図１のインターネット・アウェア装置１１３及び１１４などのインターネット・アウェア装置に結びつけ、埋め込み、又は組み込むことができ、図１のゲートウェイ１０３又は１０４などのゲートウェイを使用することなく、ほぼ本明細書で開示したような新規なストリーミング・プロトコル（例えばＴ．３８ ＵＤＰＴＬ ｏｖｅｒ ＲＴＰ型通信）が可能となる。
【００９４】
一般には、本開示で開示される方法を使用して、今日知られている、又は将来考案されるファックス中継プロトコル又は標準にほぼ準拠することのできるファックス・データ（及び／又はファックス関連データ）をＲＴＰヘッダと共にカプセル化することができる。ＲＴＰヘッダと共にカプセル化された任意のファックス・データ（及び／又はファックス関連データ）を、ＲＴＰパケットのペイロードとして、好ましくはファックス・パケットの形でよいＲＴＰパケット内のファックス・データとしてパケット交換ネットワークを介して通信することができる。例えば、Ｔ．３８経路でファックス・データを処理し、Ｔ．３８ ＵＤＰＴＬ型ファックス・パケット（Ｔ．３８パケットと呼ばれる）を得ることができる。より一般には、ＦＲＰ経路でファックス・データを処理し、ＦＲＰ型ファックス・パケット（ＦＲＰパケット）を得ることができる。ゲートウェイ７００は、ファックス・データ（Ｔ．３８ ＵＤＰＴＬ）の１タイプを処理する例示的ゲートウェイであるのに対して、図８及び９は、第２のタイプのファックス・データ（ＰＲＰ）を指す。
【００９５】
次に図８を参照すると、ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造（８００で示される）が示されている。ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケット８００は、ＲＴＰヘッダ（８０２で示される）と共にカプセル化されたＦＲＰパケット（８０１で示される）を含むことができる。得られるＲＴＰパケットを、ＵＤＰヘッダ（８０３で示される）と共に更にカプセル化することができ、次いでＩＰヘッダ（８０４で示される）と共にカプセル化し、ＦＲＰパケットをＲＴＰパケットとして送信することができる。
【００９６】
次に図９を参照すると、（図８に示されるようなモデルに準拠した構造の）ＦＲＰ（ＦｏＩＰ）パケットと、本開示の幾つかの実施形態によるＲＴＰパケットとを通信するゲートウェイ（全体的に９００で示される）の例示的ブロック図が示されている。ゲートウェイ９００のレイアウト及び機能は、図９のＦＲＰ Ｐｒｉｍａｒｙ ９０３及びＦＲＰパケッタイザ９０４がそれぞれ図７のＴ．３８ ＩＦＰパケッタイザ７０３及びＴ．３８ ＵＤＰＴＬパケッタイザ７０４に置き換わり、ファックス通信に関連するインバウンドＦＲＰ経路を形成することを除いて、ゲートウェイ７００のレイアウト及び機能と同様でよい。同様に、図９のＦＲＰデパケッタイザ９２３と、ＦＲＰ誤り回復９２５と、ＦＲＰデコーダ９２７とが、それぞれ図７のＴ．３８デパケッタイザ７２３と、Ｔ．３８ ＵＤＰＴＬ誤り７２５と、Ｔ．３８デコーダ７２７とに置き換わり、ファックス通信に関連するアウトバウンドＦＲＰ経路を形成する。
【００９７】
ゲートウェイ９００のファックス・インバウンド経路９０１は、図７のファックス受信機７０２と同様に機能する（ファックス受信モジュールである）ファックス受信機９０２と、ＦＲＰ１次パケッタイザ９０３と、ＦＲＰパケッタイザ９０４とを含むことができる。即ち、ファックス受信機９０２は、アナログ・ファックス伝送（この例ではＦａｘ Ｓａｍｐｌｅｓ Ｉｎ ９６１）をファックス・データセット（この例ではＴ．３０制御及びファックス・イメージ・データ９６４）に変換することができる。ＦＲＰ１次パケッタイザ９０３は、Ｔ．３０制御及びＦａｘイメージ・データ９６４から、対応するＦＲＰ１次パケット（９６５で示される）を生成する。ＦＲＰパケッタイザ９０４は、対応するＦＲＰパケット９６６を生成する。ゲートウェイ９００のインバウンド経路９０１はまた、ゲートウェイ９００のＲＴＰインバウンド経路を形成し、図５ｂのゲートウェイ５６０内のそれぞれユニット５７０及び５７１と一般にほぼ同様に機能するユニット９７０及び９７１も含む。ユニット９７１（ＲＴＰパケッタイザ９７１）をファックス・インバウンド経路とＲＴＰインバウンド経路の両方で使用することができる（同時にではない）。状態マシン９１１は一般に、図７の状態マシン７１１とほぼ同様に機能する。ＲＴＰ通信では、Ｔｉｍｅ ９７７は一般に、図７のＴｉｍｅ ７７７とほぼ同様に機能する。パケット・インターフェース９０５は一般に、図７のゲートウェイ７００内のパケット・インターフェース７０５とほぼ同様に機能するのに対して、ＲＴＰパケットでは、パケット・インターフェース９０５は一般に、図７のゲートウェイ７００内のパケット・インターフェース７０５とほぼ同様に機能する。ＦＲＰ１次パケッタイザ９０３と、ＦＲＰパケッタイザ９０４と、ＲＴＰパケッタイザ９７１とは、ＩＰ通信モジュールを形成することができ、ＩＰ通信モジュールは、第１ストリーミング・プロトコル（この例ではＦＲＰ）を使用してファックス・データセット（９６４で示される）をまずカプセル化し、ファックス・パケット（９６６で示される）を得、次いで、第２ストリーミング・プロトコル（この例ではＲＴＰ）を使用して、得られたカプセル化ファックス・パケット（９６６で示される）を更にカプセル化する。
【００９８】
ゲートウェイ９００のファックス・アウトバウンド経路９１２は、ユニット９２３、９２５、９２７、９２９、及び９３０を含むことができる。ゲートウェイ９００のアウトバウンド経路９１２はまた、ゲートウェイ９００のＲＴＰアウトバウンド経路を形成し、図７のゲートウェイ７００内のそれぞれユニット７９１、７９３、７９５、及び７９８と一般にほぼ同様に機能するユニット９９１、９９３、９９５、及び９９８も含む。ゲートウェイ９００のアウトバウンド経路９３２はまた、図５ｂのゲートウェイ５６０内のＩＰ Ｔｉｍｅ ５９６（又は図６のゲートウェイ６００内のＩＰ Ｔｉｍｅ ６４６）とほぼ同様に機能するＩＰ Ｔｉｍｅ（図示せず）も含む。ＦｏＩＰパケットでは、パケット・インターフェース９２１は一般に、図７のゲートウェイ７００内のパケット・インターフェース７２１とほぼ同様に機能する。ＲＴＰパケットでは、パケット・インターフェース９２１は一般に、図７のゲートウェイ７００内のパケット・インターフェース７２１とほぼ同様に機能する。ファックス送信機９３０は一般に、図７のゲートウェイ７００内のファックス送信機７３０とほぼ同様に機能する。
【００９９】
図９のゲートウェイ９００のインバウンド経路９０１に関して、ゲートウェイ９００に対する入力ソース（９６０）は、ファックス信号（Ｆａｘ Ｓａｍｐｌｅｓ Ｉｎ ９６１）又は音声（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ９６２）でよく、それらは、ファックス・マシン、マルチメディア装置（図示せず）などから発生又は転送させることができる。ゲートウェイ７００と同様に、ゲートウェイ９００は、ＲＴＰを介してファックス通信を通信すると共に、ＲＴＰ関連データ／情報が従来の方式で通信されるように設計される。本開示の一部として、ゲートウェイ９００が、ファックス・データ、又はＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９１０などのファックス関連データ／情報をＩＰネットワーク（図示せず）に送信するときはいつでも、ＲＴＰパケットのペイロードは、関連するＦＲＰパケット９６３全体である。即ち、Ｔ．３０制御／ファックス・イメージ・データ９６４が、従来通りＦＲＰ１次パケッタイザ９０３で処理され、対応する標準ＦＲＰ１次パケット（９６５）が生成され、その対応する標準ＦＲＰ１次パケット（９６５）が、ＦＲＰパケッタイザ９０４で処理され、対応するＦＲＰパケット（９６６）が生成される。
【０１００】
ゲートウェイ９００のアウトバウンド経路９１２に関して、ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９１０などのＦｏＩＰパケットがパケット・インターフェース９２１で受信されるときはいつでも、パケット・インターフェース９２１は、ＦｏＩＰパケットのＩＰ及びＵＤＰヘッダからＦｏＩＰパケットをカプセル化解除し、この場合、ＲＴＰパケットのペイロードを伴うＲＴＰパケットと、ＦｏＩＰパケットとを（ＦＲＰフォーマットの形式で）抽出する。ＲＴＰパケットのヘッダを、前述のようにＲＴＰプロトコルの従来の特徴である統計評価のために、ＲＴＣＰ９９３で使用することができる。次いで、ＦＲＰパケットを、ＦＲＰデパケッタイザ９２３と、ＦＲＰ誤り回復９２５と、ＦＲＰデコーダ９２７と、Ｔ．３０／イメージ・データ・バッファ９２９と、ファックス送信機９３０とを含むことのできる従来のＦＲＰ経路で従来通り処理することができる。
【０１０１】
音声が通信されるときはいつでも、音声は、ゲートウェイ９００で従来の方式で処理される。即ち、音声に関連する信号（Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ ９６２）がボイス・エンコーダ９７０で符号化され、符号化データがＲＴＰパケッタイザ９７１に転送され（９６８）、ＲＴＰパケッタイザ９７１は、例えば図５ｂ（それぞれ５７２及び５７６）に示すのと同様に、この時にはＲＴＰヘッダと、１次パケット及び冗長性パケットを含むＲＴＰペイロードとからなるＲＴＰパケット（９５１で示される）をパケット・インターフェース９０５に転送する。次いで、パケット・インターフェース９０５は、ＲＴＰパケット（ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９６７）をＵＤＰヘッダ及びＩＰヘッダと共にカプセル化した後に、ＲＴＰパケットを、ＩＰネットワーク（図示せず）に送信することができ、所期の受信側ゲートウェイ又は他の受信側装置に送信することができる。
【０１０２】
ゲートウェイ９００のアウトバウンド経路９１２に関して、ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ ９６７などのＶｏＩＰパケットがパケット・インターフェース９２１で受信されるときはいつでも、パケット・インターフェース９２１は、ＶｏＩＰパケットのＩＰヘッダ及びＵＤＰヘッダからＶｏＩＰパケットをカプセル化解除し、この場合は（標準ＲＴＰフォーマットの）ＶｏＩＰパケットであるＲＴＰパケットをそのＲＴＰペイロードと共に抽出する。ＲＴＣＰ９９３は、統計評価のためにＲＴＰパケットのヘッダを使用することができる。次いで、ＲＴＰデパケッタイザ９９１と、ＲＴＰプレイアウト・バッファ９９５と、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ９９８とを含むことのできる従来のＲＴＰ経路でＲＴＰパケットを通常通り処理することができる。
【０１０３】
ＲＴＰデパケッタイザ９９１によるＲＴＰパケット化解除の結果として、送信されるＲＴＰシーケンス番号、ＲＴＰタイムスタンプ、及び／又はタイムスタンプ・オフセット、１次（ＶｏＩＰ）パケット、並びに冗長性データ又はパケットが抽出され（例えば図５ｂの５９４として示される）、（誤り回復及び）ＲＴＰプレイアウト・バッファ９９５で使用されて、パケット・シーケンスが補正され、紛失パケットが回復され、Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ ９９８での使用のために一時的にパケットが格納される。ゲートウェイ９００などのゲートウェイは、図７のゲートウェイ７００に関連して説明した利点と同様の、従来技術のゲートウェイに勝る幾つかの利点を有する。
【０１０４】
図９の新規なゲートウェイに関して、ＦＲＰ標準及びＲＴＰプロトコルの点で変更は不要である。本明細書で開示される新規なプロトコル（ＦＲＰ ｏｖｅｒ ＲＴＰ又はＦＲＰ／ＲＴＰ）は、ＦＲＰパケットを９０５として示されるパケット・インターフェースに直接送信するのではなく、９７１として示されるＲＴＰパケッタイザへのＦＲＰパケットの比較的単純なリダイレクトを使用する。ＦＲＰ／ＲＴＰ型パケットがパケット・インターフェース９２１で受信されるとき、ゲートウェイ９００は、ＲＴＰデパケッタイザ９９１などのＲＴＰデパケッタイザにＲＴＰパケット全体をリダイレクトするのではなく、ＲＴＰパケット・ペイロード（１次ＲＴＰ）をＦＲＰデパケッタイザ９２３などのＦＲＰデパケッタイザにリダイレクトする。
【０１０５】
図７のゲートウェイ７００と同様に、図９のゲートウェイ９００の新規な機能を、図１のインターネット・アウェア装置１１３及び１１４などのインターネット・アウェア装置に結びつけ、埋め込み、又は組み込むことができ、図１のゲートウェイ１０３又は１０４などのゲートウェイを使用することなく、ほぼ本明細書で開示したような新規なＦＲＰ ｏｖｅｒ ＲＴＰ型通信が可能となる。更に、図７のゲートウェイ７００などのゲートウェイ又は図９のゲートウェイ９００は、コントローラを含むことができる。
【０１０６】
本開示の幾つかの特徴を図示し、本明細書で説明したが、多数の修正と、置換と、変更と、均等物とが当業者には今や思い浮かぶであろう。従って、添付の特許請求の範囲は、本開示の真の精神の中に含まれるすべての修正及び変更を包含するものとする。
【図面の簡単な説明】
【０１０７】
【図１】例示的な基本的ＦｏＩＰ／ＶｏＩＰシステムの略図である。
【図２】ファックス通信で使用されるＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である（従来技術）。
【図３】ＩＦＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である（従来技術）。
【図４】本開示のある実施形態によるＴ．３８ ＵＤＰＴＬ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である。
【図５ａ】図２に示されるパケット・モデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットを通信する従来型ゲートウェイのブロック図である。
【図５ｂ】ＩＰネットワークを介してＲＴＰパケット・ストリームを通信する従来型ゲートウェイのブロック図である。
【図６】図３に示されるパケット・モデルに準拠する構造のＦｏＩＰパケットを通信する例示的な従来型ゲートウェイの略図である。
【図７】図４に示すモデルに準拠する構造のＴ．３８ ＵＤＰＴＬ（ＦｏＩＰ）パケットと、本開示のある実施形態によるＲＴＰパケットとを通信するゲートウェイの例示的ブロック図である。
【図８】ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケットの一般的構造を示す図である（従来技術）。
【図９】図８に示されるようなモデルに準拠した構造のＦＲＰ（ＦｏＩＰ）パケットと、本開示の幾つかの実施形態によるＲＴＰパケットとを通信するゲートウェイの例示的ブロック図である。
【符号の説明】
【０１０８】
１００ ＦｏＩＰ／ＶｏＩＰシステム
１０１ ファックス・マシン
１０２ ファックス・マシン
１０３ ゲートウェイ
１０４ ゲートウェイ
１０５ ＰＳＴＮ回線接続
１０６ ＰＳＴＮ回線接続
１０７ ＩＰネットワーク
１１１ ネットワーク接続
１１２ ネットワーク接続
１１３ インターネット・アウェア装置
１１４ インターネット・アウェア装置
１１５ 接続回線
１１６ 接続回線
２００ ＩＦＰ／ＵＤＰＴＬ／ＵＤＰ／ＩＰパケット
２０１ ＩＦＰパケット
２０２ 冗長性パケット
２０３ ＦＥＣメッセージ
２０４ ＵＤＰＴＬヘッダ
２０５ ユーザ・データグラム・プロトコル（「ＵＤＰ」）ヘッダ
２０６ ＩＰヘッダ
３０１ ＩＦＰパケット
３０２ パケット
３０３ パケット
３０４ ＲＴＰヘッダ
４０１ 標準Ｔ．３８ ＵＤＰＴＬパケット
４０２ ＲＴＰヘッダ
５００ ゲートウェイ
５０１ インバウンド・ファックス・データ／情報処理経路
５０２ ファックス受信機
５０３ Ｔ．３８ ＩＦＰパケッタイザ
５０４ Ｔ．３８ ＵＤＰＴＬパケッタイザ
５０５ パケット・インターフェース
５０７ Ｔ．３０制御及びファックス・データ
５０８ Ｔ．３８ ＩＦＰパケット
５０９ Ｔ．３８ ＵＤＰＴＬパケット
５１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
５１１ ファックス中継状態マシン
５２０ ＦｏＩＰ Ｐａｃｋｅｔ Ｉｎ
５２１ パケット・インターフェース
５２２ Ｔ．３８ ＵＤＰＴＬパケット
５２３ Ｔ．３８ ＵＤＰＴＬデパケッタイザ
５２４ ＵＤＰＴＬシーケンス番号、Ｔ．３８ ＩＦＰパケット、冗長性又はＦＥＣフレーム
５２５ Ｔ．３８ ＵＤＰＴＬ誤り回復モジュール
５２６ Ｔ．３８ ＩＦＰパケット
５２７ Ｔ．３８デコーダ
５２８ Ｔ．３０制御及びファックス・イメージ・データ
５２９ Ｔ．３０／イメージ・データ・バッファ
５３０ ファックス送信機
５３１ Ｆａｘ Ｓａｍｐｌｅｓ Ｏｕｔ
５３５ シーケンス番号
５３６ Ｔ．３８ ＵＤＰＴＬ冗長性フレーム
５５１ ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
５５２ ＶｏＩＰ Ｐａｃｋｅｔ Ｉｎ
５６０ ゲートウェイ
５６１ Ｓａｍｐｌｅｓ Ｉｎ
５６２ Ｓａｍｐｌｅｓ Ｏｕｔ
５７０ ボイス・エンコーダ
５７１ ＲＴＰパケッタイザ
５７２ ＲＴＰ１次パケット情報
５７６ 冗長性データ
５７７ Ｔｉｍｅ
５７８ ＲＴＰパケット
５７９ ヘッダ
５８０ パケット・インターフェース
５８１ パケット・インターフェース
５９１ ＲＴＰデパケッタイザ
５９３ ＲＴＣＰ Ｓｔａｔｉｓｔｉｃｓ
５９４ ＲＴＰエラー回復
５９５ プレイアウト・バッファ
５９６ Ｔｉｍｅ
５９７ ＲＴＰタイムスタンプ
５９８ Ｖｏｉｃｅ Ｄｅｃｏｄｅ Ｐｌａｙ
６００ ゲートウェイ
６０１ インバウンド経路
６０２ ファックス受信機
６０３ Ｔ．３８ ＩＦＰパケッタイザ
６０５ パケット・インターフェース
６１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
６１１ 状態マシン
６１２ アウトバウンド経路
６４１ ＲＴＰデパケッタイザ
６４６ ＩＰ Ｔｉｍｅ
６４９ ＲＴＰパケッタイザ
７００ ゲートウェイ
７０１ インバウンド経路
７０２ ファックス受信機
７０３ Ｔ．３８ ＩＦＰパケッタイザ
７０４ Ｔ．３８ ＵＤＰＴＬパケッタイザ
７０５ パケット・インターフェース
７１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
７１１ 状態マシン
７１２ アウトバウンド経路
７２１ パケット・インターフェース
７２３ Ｔ．３８ ＵＤＰＴＬデパケッタイザ
７２５ Ｔ．３８ ＵＤＰＴＬ誤り回復
７２７ Ｔ．３８デコーダ
７２９ Ｔ．３０／イメージ・データ・バッファ
７３０ ファックス送信機
７６０ 入力ソース
７６２ Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ
７６３ Ｔ．３８ ＵＤＰＴＬパケット
７６４ Ｔ．３０制御／ファックス・イメージ・データ
７６５ 標準Ｔ．３８ ＩＦＰパケット
７６６ Ｔ．３８ ＵＤＰＴＬパケット
７６７ ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
７７０ ボイス・エンコーダ
７７１ ＲＴＰパケッタイザ
７７７ Ｔｉｍｅ
７９１ ＲＴＰデパケッタイザ
７９３ ＲＴＣＰ ｓｔａｔｉｓｔｉｃｓ
７９５ 誤り回復及びＲＴＰプレイアウト・バッファ
７９８ Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ（Ｐｌａｙ）
８００ ＦＲＰ／ＲＴＰ／ＵＤＰ／ＩＰパケット
８０１ ＦＲＰパケット
８０２ ＲＴＰヘッダ
８０３ ＵＤＰヘッダ
８０４ ＩＰヘッダ
９００ ゲートウェイ
９０１ ファックス・インバウンド経路
９０２ ファックス受信機
９０３ ＦＲＰ１次パケッタイザ
９０４ ＰＲＰパケッタイザ
９０５ パケット・インターフェース
９１０ ＦｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
９１１ 状態マシン
９１２ ファックス・アウトバウンド経路
９２１ パケット・インターフェース
９２３ ＦＲＰデパケッタイザ
９２５ ＦＲＰ誤り回復
９２７ ＦＲＰデコーダ
９２９ Ｔ．３０／イメージ・データ・バッファ
９３０ ファックス送信機
９３２ アウトバウンド経路
９５１ ＲＴＰパケット
９６０ 入力ソース
９６１ Ｆａｘ Ｓａｍｐｌｅｓ Ｉｎ
９６２ Ｖｏｉｃｅ Ｓａｍｐｌｅｓ Ｉｎ
９６３ ＦＲＰパケット
９６４ Ｔ．３０制御／ファックス・イメージ・データ
９６５ 標準ＦＲＰ１次パケット
９６６ ＦＲＰパケット
９６７ ＶｏＩＰ Ｐａｃｋｅｔ Ｏｕｔ
９７０ ボイス・エンコーダ
９７１ ＲＴＰパケッタイザ
９７７ Ｔｉｍｅ
９９１ ＲＴＰデパケッタイザ
９９５ ＲＴＰプレイアウト・バッファ
９９８ Ｖｏｉｃｅ Ｄｅｃｏｄｅｒ Ｐｌａｙ
【特許請求の範囲】
【請求項１】
ゲートウェイであって、
アナログ・ファックス伝送をファックス・データセットに変換するように適合されたファックス受信モジュールと、
前記データセットを第１ストリーミング・プロトコルを使用してカプセル化し、このカプセル化データセットを第２ストリーミング・プロトコルを使用して更にカプセル化するように適合されたＩＰ通信モジュールと、
を備えるゲートウェイ。
【請求項２】
請求項１に記載のゲートウェイであって、前記第１ストリーミング・プロトコルは、ファックス中継プロトコルであり、第２ストリーミング・プロトコルは、リアル・タイム・プロトコルである、ゲートウェイ。
【請求項３】
請求項２に記載のゲートウェイであって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルである、ゲートウェイ。
【請求項４】
請求項１に記載のゲートウェイであって、前記受信モジュール及び前記ＩＰ通信モジュールは、前記アナログ・ファックス伝送を受信し、前記アナログ・ファックス伝送からファックス・パケットを生成し、前記ファックス・パケットをリアル・タイム・プロトコルを使用してカプセル化するように適合されたインバウンド・ファックス経路を形成する、ゲートウェイ。
【請求項５】
請求項４に記載のゲートウェイであって、前記インバウンド・ファックス経路は、ファックス中継プロトコル経路であり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、ゲートウェイ。
【請求項６】
請求項５に記載のゲートウェイであって、前記インバウンド・ファックス中継プロトコル経路は、
アナログ・ファックス伝送からデータセットを生成するように適合されたファックス受信機と、
前記ファックス受信機に結合され、前記データセットからファックス中継プロトコル１次パケットを生成するように適合されたファックス中継プロトコル１次パケッタイザと、
前記ファックス中継プロトコル１次パケッタイザに結合され、前記ファックス中継プロトコル１次パケットからファックス中継プロトコル・パケットを生成するように適合されたファックス中継プロトコル・パケッタイザと、
前記ファックス中継プロトコル・パケットをカプセル化するように適合されたリアル・タイム・プロトコル・パケッタイザと、
を含む、ゲートウェイ。
【請求項７】
請求項４に記載のゲートウェイであって、前記インバウンド・ファックス中継プロトコル経路は、Ｔ．３８経路であり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、ゲートウェイ。
【請求項８】
請求項７に記載のゲートウェイであって、前記インバウンドＴ．３８経路は、
受信した前記アナログ・ファックス伝送から前記データセットを生成するように適合されたファックス受信機と、
前記ファックス受信機に結合され、前記データセットＴ．３０制御及びファックス・イメージ・データからＴ．３８ ＩＦＰパケットを生成するように適合されたＴ．３８ ＩＦＰパケッタイザと、
前記Ｔ．３８ ＩＦＰパケッタイザに結合され、前記Ｔ．３８ ＩＦＰパケットからＴ．３８ ＵＤＰＴＬパケットを生成するように適合されたＴ．３８ ＵＤＰＴＬパケッタイザと、
前記ファックス中継プロトコル・パケットをカプセル化するように適合されたリアル・タイム・プロトコル・パケッタイザと、
を含む、ゲートウェイ。
【請求項９】
請求項６に記載のゲートウェイであって、前記データセットは、Ｔ．３０制御データ及びファックス・イメージ・データを含む、ゲートウェイ。
【請求項１０】
請求項４に記載のゲートウェイであって、
インバウンド・リアル・タイム・プロトコル経路を、
更に備え、前記インバウンド・リアル・タイム・プロトコル経路は、
入力音声／オーディオ信号に関する符号化データを生成するように適合されたボイス・エンコーダと、
前記ボイス・エンコーダに結合され、前記符号化データの部分をそれぞれのリアル・タイム・プロトコル・ヘッダと共にカプセル化することによってリアル・タイム・プロトコル・パケットを生成するように適合されたリアル・タイム・プロトコル・パケッタイザと、
を含む、ゲートウェイ。
【請求項１１】
請求項４に記載のゲートウェイであって、
送信モジュールを、
更に備え、
前記送信モジュール及び前記ＩＰ通信モジュールは、前記第２ストリーミング・プロトコルを使用して、カプセル化ファックス・データセットを含むファックス・パケットをカプセル化解除し、前記第１ストリーミング・プロトコルを使用して、前記カプセル化ファックス・データセットを更にカプセル化解除するように適合されたアウトバウンド・ファックス経路を形成する、ゲートウェイ。
【請求項１２】
請求項１１に記載のゲートウェイであって、前記アウトバウンド・ファックス経路は、ファックス中継プロトコル経路であり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、ゲートウェイ。
【請求項１３】
請求項１５に記載のゲートウェイであって、前記アウトバウンド・ファックス中継プロトコル経路は、リアル・タイム・プロトコル・カプセル化ファックス中継プロトコル・パケットをカプセル化解除し、前記ファックス中継プロトコル経路内のファックス中継プロトコル・パケットを処理して、対応するファックス信号を生成するように適合される、ゲートウェイ。
【請求項１４】
請求項１２に記載のゲートウェイであって、前記アウトバウンド・ファックス中継プロトコル経路は、
前記第２ストリーム・プロトコルを使用して、前記ファックス中継プロトコル・パケットをカプセル化解除し、カプセル化ファックス・データセットを得るように適合されたパケット・インターフェースと、
前記第１ストリーム・プロトコルを使用して、前記カプセル化ファックス・データセットをカプセル化解除するように適合されたファックス中継プロトコル・デパケッタイザと、
前記ファックス中継プロトコル・デパケッタイザに結合され、前記ファックス・データセットを復号化するように適合されたファックス中継プロトコル・デコーダと、
前記データセットからアナログ・ファックス信号を生成及び出力するように適合されたファックス送信機と、
を含む、ゲートウェイ。
【請求項１５】
請求項１２に記載のゲートウェイであって、前記アウトバウンド・ファックス中継プロトコル経路は、Ｔ．３８経路であり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、ゲートウェイ。
【請求項１６】
請求項１５に記載のゲートウェイであって、前記アウトバウンドＴ．３８経路は、
リアル・タイム・プロトコル・カプセル化Ｔ．３８ ＵＤＰＴＬパケットをカプセル化解除し、前記Ｔ．３８経路内のＴ．３８ ＵＤＰＴＬパケットを処理して、対応するファックス信号を生成するように適合されたアウトバウンドＴ．３８経路を含む、ゲートウェイ。
【請求項１７】
交換パケット・ネットワークを介してファックス・データを送信する機器であって、
第１ストリーミング・プロトコルを使用してファックス・データセットをカプセル化し、ファックス・パケットを得、第２ストリーミング・プロトコルを使用して前記ファックス・パケットを更にカプセル化するように適合されたコントローラを、
備える機器。
【請求項１８】
請求項１７に記載の機器であって、前記第１ストリーミング・プロトコルは、ファックス中継プロトコルである、機器。
【請求項１９】
請求項１８に記載の機器であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、機器。
【請求項２０】
請求項１７に記載の機器であって、前記第２ストリーミング・プロトコルは、リアル・タイム・プロトコルである、機器。
【請求項２１】
請求項１７に記載の機器であって、｛携帯電話、ファックス、モデム｝からなるグループから選択されたインターネット・アウェア装置である機器。
【請求項２２】
交換パケット・ネットワークを介してファックス・データを受信する機器であって、
第１ストリーミング・プロトコルを使用してファックス・パケットを抽出し、第２ストリーミング・プロトコルを使用して前記ファックス・パケットからデータセットを抽出するように適合されたコントローラを、
備える機器。
【請求項２３】
請求項２２に記載の機器であって、前記第１ストリーミング・プロトコルは、リアル・タイム・プロトコルである、機器。
【請求項２４】
請求項２２に記載の機器であって、前記第２ストリーミング・プロトコルは、ファックス中継プロトコルであり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、機器。
【請求項２５】
請求項２４に記載の機器であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、機器。
【請求項２６】
請求項２２に記載の機器であって、｛携帯電話、ファックス、モデム｝からなるグループから選択されたインターネット・アウェア装置である機器。
【請求項２７】
交換パケット・ネットワークを介してファックス・データセットを送信する方法であって、
第１ストリーミング・プロトコルを使用してファックス・データセットをカプセル化し、ファックス・パケットを得、第２ストリーミング・プロトコルを使用して前記ファックス・パケットを更にカプセル化すること、
を含む方法。
【請求項２８】
請求項２７に記載の方法であって、前記第１ストリーミング・プロトコルは、ファックス中継プロトコルであり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、方法。
【請求項２９】
請求項２８に記載の方法であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、方法。
【請求項３０】
請求項２７に記載の方法であって、前記第２ストリーミング・プロトコルは、リアル・タイム・プロトコルである、方法。
【請求項３１】
交換パケット・ネットワークからファックス・データセットを受信する方法であって、
第１ストリーミング・プロトコルを使用して、受信したパケットをカプセル化解除し、ファックス・パケットを得ること、及び
第２ストリーミング・プロトコルを使用して前記ファックス・パケットをカプセル化解除し、ファックス・データセットを得ること、
を含む方法。
【請求項３２】
請求項３１に記載の方法であって、前記第１ストリーミング・プロトコルは、リアル・タイム・プロトコルである、方法。
【請求項３３】
請求項３１に記載の方法であって、前記第２ストリーミング・プロトコルは、ファックス中継プロトコルであり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、方法。
【請求項３４】
請求項３３に記載の方法であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、方法。
【請求項１】
ゲートウェイであって、
アナログ・ファックス伝送をファックス・データセットに変換するように適合されたファックス受信モジュールと、
前記データセットを第１ストリーミング・プロトコルを使用してカプセル化し、このカプセル化データセットを第２ストリーミング・プロトコルを使用して更にカプセル化するように適合されたＩＰ通信モジュールと、
を備えるゲートウェイ。
【請求項２】
請求項１に記載のゲートウェイであって、前記第１ストリーミング・プロトコルは、ファックス中継プロトコルであり、第２ストリーミング・プロトコルは、リアル・タイム・プロトコルである、ゲートウェイ。
【請求項３】
請求項２に記載のゲートウェイであって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルである、ゲートウェイ。
【請求項４】
請求項１に記載のゲートウェイであって、前記受信モジュール及び前記ＩＰ通信モジュールは、前記アナログ・ファックス伝送を受信し、前記アナログ・ファックス伝送からファックス・パケットを生成し、前記ファックス・パケットをリアル・タイム・プロトコルを使用してカプセル化するように適合されたインバウンド・ファックス経路を形成する、ゲートウェイ。
【請求項５】
請求項４に記載のゲートウェイであって、前記インバウンド・ファックス経路は、ファックス中継プロトコル経路であり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、ゲートウェイ。
【請求項６】
請求項５に記載のゲートウェイであって、前記インバウンド・ファックス中継プロトコル経路は、
アナログ・ファックス伝送からデータセットを生成するように適合されたファックス受信機と、
前記ファックス受信機に結合され、前記データセットからファックス中継プロトコル１次パケットを生成するように適合されたファックス中継プロトコル１次パケッタイザと、
前記ファックス中継プロトコル１次パケッタイザに結合され、前記ファックス中継プロトコル１次パケットからファックス中継プロトコル・パケットを生成するように適合されたファックス中継プロトコル・パケッタイザと、
前記ファックス中継プロトコル・パケットをカプセル化するように適合されたリアル・タイム・プロトコル・パケッタイザと、
を含む、ゲートウェイ。
【請求項７】
請求項４に記載のゲートウェイであって、前記インバウンド・ファックス中継プロトコル経路は、Ｔ．３８経路であり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、ゲートウェイ。
【請求項８】
請求項７に記載のゲートウェイであって、前記インバウンドＴ．３８経路は、
受信した前記アナログ・ファックス伝送から前記データセットを生成するように適合されたファックス受信機と、
前記ファックス受信機に結合され、前記データセットＴ．３０制御及びファックス・イメージ・データからＴ．３８ ＩＦＰパケットを生成するように適合されたＴ．３８ ＩＦＰパケッタイザと、
前記Ｔ．３８ ＩＦＰパケッタイザに結合され、前記Ｔ．３８ ＩＦＰパケットからＴ．３８ ＵＤＰＴＬパケットを生成するように適合されたＴ．３８ ＵＤＰＴＬパケッタイザと、
前記ファックス中継プロトコル・パケットをカプセル化するように適合されたリアル・タイム・プロトコル・パケッタイザと、
を含む、ゲートウェイ。
【請求項９】
請求項６に記載のゲートウェイであって、前記データセットは、Ｔ．３０制御データ及びファックス・イメージ・データを含む、ゲートウェイ。
【請求項１０】
請求項４に記載のゲートウェイであって、
インバウンド・リアル・タイム・プロトコル経路を、
更に備え、前記インバウンド・リアル・タイム・プロトコル経路は、
入力音声／オーディオ信号に関する符号化データを生成するように適合されたボイス・エンコーダと、
前記ボイス・エンコーダに結合され、前記符号化データの部分をそれぞれのリアル・タイム・プロトコル・ヘッダと共にカプセル化することによってリアル・タイム・プロトコル・パケットを生成するように適合されたリアル・タイム・プロトコル・パケッタイザと、
を含む、ゲートウェイ。
【請求項１１】
請求項４に記載のゲートウェイであって、
送信モジュールを、
更に備え、
前記送信モジュール及び前記ＩＰ通信モジュールは、前記第２ストリーミング・プロトコルを使用して、カプセル化ファックス・データセットを含むファックス・パケットをカプセル化解除し、前記第１ストリーミング・プロトコルを使用して、前記カプセル化ファックス・データセットを更にカプセル化解除するように適合されたアウトバウンド・ファックス経路を形成する、ゲートウェイ。
【請求項１２】
請求項１１に記載のゲートウェイであって、前記アウトバウンド・ファックス経路は、ファックス中継プロトコル経路であり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、ゲートウェイ。
【請求項１３】
請求項１５に記載のゲートウェイであって、前記アウトバウンド・ファックス中継プロトコル経路は、リアル・タイム・プロトコル・カプセル化ファックス中継プロトコル・パケットをカプセル化解除し、前記ファックス中継プロトコル経路内のファックス中継プロトコル・パケットを処理して、対応するファックス信号を生成するように適合される、ゲートウェイ。
【請求項１４】
請求項１２に記載のゲートウェイであって、前記アウトバウンド・ファックス中継プロトコル経路は、
前記第２ストリーム・プロトコルを使用して、前記ファックス中継プロトコル・パケットをカプセル化解除し、カプセル化ファックス・データセットを得るように適合されたパケット・インターフェースと、
前記第１ストリーム・プロトコルを使用して、前記カプセル化ファックス・データセットをカプセル化解除するように適合されたファックス中継プロトコル・デパケッタイザと、
前記ファックス中継プロトコル・デパケッタイザに結合され、前記ファックス・データセットを復号化するように適合されたファックス中継プロトコル・デコーダと、
前記データセットからアナログ・ファックス信号を生成及び出力するように適合されたファックス送信機と、
を含む、ゲートウェイ。
【請求項１５】
請求項１２に記載のゲートウェイであって、前記アウトバウンド・ファックス中継プロトコル経路は、Ｔ．３８経路であり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、ゲートウェイ。
【請求項１６】
請求項１５に記載のゲートウェイであって、前記アウトバウンドＴ．３８経路は、
リアル・タイム・プロトコル・カプセル化Ｔ．３８ ＵＤＰＴＬパケットをカプセル化解除し、前記Ｔ．３８経路内のＴ．３８ ＵＤＰＴＬパケットを処理して、対応するファックス信号を生成するように適合されたアウトバウンドＴ．３８経路を含む、ゲートウェイ。
【請求項１７】
交換パケット・ネットワークを介してファックス・データを送信する機器であって、
第１ストリーミング・プロトコルを使用してファックス・データセットをカプセル化し、ファックス・パケットを得、第２ストリーミング・プロトコルを使用して前記ファックス・パケットを更にカプセル化するように適合されたコントローラを、
備える機器。
【請求項１８】
請求項１７に記載の機器であって、前記第１ストリーミング・プロトコルは、ファックス中継プロトコルである、機器。
【請求項１９】
請求項１８に記載の機器であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、機器。
【請求項２０】
請求項１７に記載の機器であって、前記第２ストリーミング・プロトコルは、リアル・タイム・プロトコルである、機器。
【請求項２１】
請求項１７に記載の機器であって、｛携帯電話、ファックス、モデム｝からなるグループから選択されたインターネット・アウェア装置である機器。
【請求項２２】
交換パケット・ネットワークを介してファックス・データを受信する機器であって、
第１ストリーミング・プロトコルを使用してファックス・パケットを抽出し、第２ストリーミング・プロトコルを使用して前記ファックス・パケットからデータセットを抽出するように適合されたコントローラを、
備える機器。
【請求項２３】
請求項２２に記載の機器であって、前記第１ストリーミング・プロトコルは、リアル・タイム・プロトコルである、機器。
【請求項２４】
請求項２２に記載の機器であって、前記第２ストリーミング・プロトコルは、ファックス中継プロトコルであり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、機器。
【請求項２５】
請求項２４に記載の機器であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、機器。
【請求項２６】
請求項２２に記載の機器であって、｛携帯電話、ファックス、モデム｝からなるグループから選択されたインターネット・アウェア装置である機器。
【請求項２７】
交換パケット・ネットワークを介してファックス・データセットを送信する方法であって、
第１ストリーミング・プロトコルを使用してファックス・データセットをカプセル化し、ファックス・パケットを得、第２ストリーミング・プロトコルを使用して前記ファックス・パケットを更にカプセル化すること、
を含む方法。
【請求項２８】
請求項２７に記載の方法であって、前記第１ストリーミング・プロトコルは、ファックス中継プロトコルであり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、方法。
【請求項２９】
請求項２８に記載の方法であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、方法。
【請求項３０】
請求項２７に記載の方法であって、前記第２ストリーミング・プロトコルは、リアル・タイム・プロトコルである、方法。
【請求項３１】
交換パケット・ネットワークからファックス・データセットを受信する方法であって、
第１ストリーミング・プロトコルを使用して、受信したパケットをカプセル化解除し、ファックス・パケットを得ること、及び
第２ストリーミング・プロトコルを使用して前記ファックス・パケットをカプセル化解除し、ファックス・データセットを得ること、
を含む方法。
【請求項３２】
請求項３１に記載の方法であって、前記第１ストリーミング・プロトコルは、リアル・タイム・プロトコルである、方法。
【請求項３３】
請求項３１に記載の方法であって、前記第２ストリーミング・プロトコルは、ファックス中継プロトコルであり、前記ファックス・パケットは、ファックス中継プロトコル・パケットである、方法。
【請求項３４】
請求項３３に記載の方法であって、前記ファックス中継プロトコルは、Ｔ．３８ ＵＤＰＴＬプロトコルであり、前記ファックス・パケットは、Ｔ．３８ ＵＤＰＴＬパケットである、方法。
【図１】
【図２】
【図３】
【図４】
【図５ａ】
【図５ｂ】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５ａ】
【図５ｂ】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００７−２７４６９２（Ｐ２００７−２７４６９２Ａ）
【公開日】平成１９年１０月１８日（２００７．１０．１８）
【国際特許分類】
【出願番号】特願２００７−９００７６（Ｐ２００７−９００７６）
【出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（５０４１６３９１１）オーディオコーズ・リミテッド (3)
【氏名又は名称原語表記】ＡＵＤＩＯＣＯＤＥＳ ＬＴＤ．
【Ｆターム（参考）】
【公開日】平成１９年１０月１８日（２００７．１０．１８）
【国際特許分類】
【出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（５０４１６３９１１）オーディオコーズ・リミテッド (3)
【氏名又は名称原語表記】ＡＵＤＩＯＣＯＤＥＳ ＬＴＤ．
【Ｆターム（参考）】
[ Back to top ]