ファクス リレーのトラブルシューティング

Updated: 2024 年 5 月 22 日
Document ID:20227

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    はじめに

    このドキュメントでは、Ciscoファックスリレー関連の問題に対する基本的なトラブルシューティングと解決策について説明します。 

    前提条件

    要件

    Cisco IOS®ゲートウェイでは、パケットテレフォニーネットワークを介してファックスコールを渡すために、次のようなテクニックが使用されることに注意してください。

    • Cisco 独自方式のファックス リレー

    • T.38 FAX リレー

    • ファックス パススルー

    • ファックス アップスピード

    • T.37 標準のストア アンド フォワード ファックス

    また、今日では次の 3 つの主要なパケット テレフォニー テクノロジーが使用されています。これらはまとめて Voice over "X"（VoX）と呼ばれるものです。

    • Voice over IP（VoIP）

    • Voice over Frame Relay（VoFR）

    • Voice over ATM（VoATM）

    このドキュメントでは、主にVoIPネットワークで動作するCisco IOSゲートウェイ上のCisco独自のファックスリレーに焦点を当てています。T.38ファックスリレーとその他のVoXテクノロジーについても説明します。

    ファックスとファックスリレーに関する技術的な内容については詳しく説明していませんが、ファックスリレーに関する一般的な問題の大半をトラブルシューティングできます。FAX と Cisco FAX リレーの概要についても説明します。

    使用するコンポーネント

    このドキュメントの情報は主にCisco IOSソフトウェアリリース12.2(5)に基づいていますが、ほとんどの情報は他のCisco IOSソフトウェアリリースにも役立ちます。

    デバッグ情報の一部は、Cisco IOS ソフトウェア リリース 12.2(7) が稼働している Cisco IOS ゲートウェイから取得しています。これについては、このドキュメントの「デバッグ」セクションで説明しています。

    このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

    ファックスおよびファックス リレーの概要

    現在のファックス機器のほとんどは Group 3 に準拠しています。Fax Group 3 は主に T.4 および T.30 の ITU 勧告で構成されている、標準ベースのテクノロジーです。

    T.4 は、ファックス機器によるファックス イメージの符号化方式に関するもので、T.30 はファクシミリのネゴシエーションと通信プロトコルを詳細に規定しています。

    Group 3 のファックス機器は Public Switched Telephone Network（PSTN; 公衆電話交換網）経由で使用するために設計されました。PSTNは音声通話用に設計されているため、Group 3ではアナログモデムと同様にアナログ符号化または変調信号を使用します。

    アナログ モデムおよびファクス機器は、PSTN 経由でデジタル情報の送受信を行うために変調したアナログ信号を使用するデジタル デバイスです。普通、この変調信号はさまざまな可聴音として聞こえます。

    VoX ネットワークのゲートウェイは、最初は音声コールとファックス コールを同じものとして扱います。どちらのタイプのコールでも、ゲートウェイはユーザによって設定された音声圧縮コーデックを Digital Signal Processor（DSP; デジタル シグナル プロセッサ）にロードします。

    DSP の詳細は、『ボイス ハードウェア：C542 および C549 デジタル信号プロセッサ（DSP）』を参照してください。

    通常、音声圧縮コーデックは高圧縮のコーデックであるため、音声コール毎に必要とする帯域幅は比較的小さくて済みます。

    G729 および G723 などの高圧縮のコーデックは、音声用に最適化されており、優れた品質を保ちながら音声を低帯域幅（8 kbps、G.729 でのオーバーヘッドは除く）に圧縮します。しかし、G.729 などの高圧縮コーデックは、ファックス用には最適化されていません。

    実際、これらのコーデックを使用したときにはファックス送信の変調信号が正しく伝わらないのが普通であり、その結果ファックス コールは失敗します。

    圧縮コーデックについての詳細は、『VoIP - コール単位の帯域幅の使用量』を参照してください。

    圧縮率の低いコーデックを使用したときや、圧縮をまったく使用しないとき（エコー キャンセルや Voice Activity Detection（VAD; 音声アクティビティ検出）のない G.726 や G.711 など）は、ファックスを正常に送信できます。

    音声コーデックを通してファックスを送信する方式は、通常、インバンド ファックス通信またはファックス パススルーと呼ばれます。

    アップスピードと呼ばれる技術では、ゲートウェイは音声コール用に、設定された音声圧縮コーデックを DSP に最初にロードし、ファックス トーンが検出された場合はそれを低圧縮コーデックに変更します。

    インバンド ファックス通信では、最初の変調信号が発信側のルータのコーデックによって符号化および圧縮され、それが音声サンプルと同じ扱いで VoX ネットワークを経由して渡されます。

    そして、終端のゲートウェイでそのサンプルが圧縮解除されてデコードされ、終端のファックス機器で再生されます。

    ファックス リレーの機能はこれとは異なります。それは、変調信号を終端して、デジタル情報を抽出し、データ パケットによりデジタル情報をデータ ネットワーク経由で中継するプロトコルです。

    終端側では、デジタル情報がパケットから抽出され、変調されて、再生されます。

    ファックスの基本

    ファックス コールは、ファックス ネゴシエーションとページ送信の 2 つの部分に分けられます。

    ファックスコールの開始時に半二重ファックスネゴシエーションが発生します。V.21変調High-level Data Link Control(HDLC)データフレームは、300 bpsの速度で渡されます。

    これらのデータフレームは、発信側と終端側のファックス デバイスの間を標準シーケンスで送られます。

    この交換では、各ファックス デバイスに相互に能力が交換され、ページ送信が行われる前に、両方のファックス デバイスでファックス セッションの特性について合意が行われます。

    次の図は、従来の PSTN 経由のファックス コールを示しています。

    20227-faxrelay-tsguide1

    ページ送信速度、Error Correction Mode（ECM; エラー訂正モード）、解像度、ページ コーディング、読み取り時間などの能力が交換され、ネゴシエートされます。

    ページ送信速度（トレーニング）は、ファックスが情報を送信する速度を決定する重要なネゴシエーションです。

    ファックスでは、最初に交換されたパラメータに基づいて、可能な最高の変調速度でトレーニングが試行されます。高速でのトレーニングが失敗した場合、ファクスデバイスは低速に再トレーニングします。

    ページ送信は、ファックス ネゴシエーション フェーズのトレーニング部分が完了すると、以前に合意済みのパラメータを使用して実行されます。ページ情報は、横 203×縦 98 dpi の標準解像度を持つスキャン ラインに符号化されます。

    ファックス イメージは、通常、Modified Huffman（MH）または Modified Read（MR）符号化のどちらかを使用して圧縮と符号化が行われます。MH は普通 20：1 の比率で圧縮します。MR 符号化は普通 MH よりも 20 % 高い圧縮率を実現しますが、エラー耐性が若干劣ります。

    ページ送信が行われる際には、コール セットアップ時のネゴシエーションで使用された初期の 300 bps よりも高いビット レートが使用されます。ページ送信に使用されるビット レートは、トレーニング中に確定されます。

    ファックス ページ送信で使用される、一般的なレートの一部を次に示します。

    • V.27ter：2400/4800 BPS

    • V.29：7200/9600 BPS

    • V.17：14400 BPS

    注：ページ送信(V.27ter、V.29、V.17)およびファックスネゴシエーション(V.21)に使用されるこれらのV.XX仕様は、デジタルデータをアナログ電話回線で送信する方法を定義する仕様です。

    データ モデムもこれらの仕様を使用できます。ただし、データ モデムのほとんどは、すでにこれらよりもさらに高速な速度に移行しています。

    ファックス リレーの基本

    ファクスリレーは、高圧縮音声コーデック（G729、g723など）がファックストラフィックを通過させようとしたときの欠点を克服するために使用される技術です。

    ファックスコールは通常の会話コールのように扱われるため、各ゲートウェイのDSPは音声モードになり、音声モードが終わると人間の会話が受信されて処理されることが期待されます。

    コールの存続中にファックス応答（CED）またはコール（CNG）トーンが聞こえた場合、この音声処理が DSP で妨げられることはありません。DSP は引き続き、そのトーンを VoX コール レッグ経由で継続できます。

    通常のファックス機器では、CED の生成後または CNG の受信後に、ファックス ハンドシェイクの一部として T.30 DIS メッセージが送信されます。このプロセスは通常、終端のファックス機器で発生します。

    次に、終端ゲートウェイのDSPが、DISメッセージの先頭でHDLCフラグシーケンスを検出し、ファックスリレーのスイッチオーバーを開始します。これは、DSP は音声コーデックをアンロードしてファックス コーデックをロードし、そのファックス コールを処理することを意味します。

    さらに、ファックス コールの双方の DSP でこのファックス コーデックが使用されるように、VoX ネットワークの相手側の DSP に通知が送られます。使用されるファックス リレー プロトコルによって、この通知メカニズムは異なります。

    ロードされたファックス コーデックにより、DSP では T.30 HDLC フレームが復調され、ファックス情報が抽出されて、次のいずれかのファックス リレー プロトコルによりルータ間でファックス情報が受け渡されます。

    • VoIP 用の Cisco 独自のファックス リレー：ファックス リレーは、VoIP ネットワーク経由でファックスを送信するためのデフォルト モードであり、Cisco ファックス リレーはデフォルトのファックス リレー タイプです。この機能は Cisco IOS ソフトウェア リリース 11.3 以降でサポートされており、広く利用されています。また、RTP を使用してファックス データを転送します。

    • VoIP 用の標準ベースの T.38 ファックス：T.38 は一部のプラットフォームで、Cisco IOS ソフトウェア リリース 12.1(3)T 以降で利用可能です。VoIP ダイヤル ピアの下で fax relay protocol t38 コマンドを設定することによって、これが有効になり、ファックス データは UDP を使用して転送されます。

    • FRF.11 Annex D 標準ベース（VoFR および VoATM 対応）

    インバンドファックスやファックスパススルーとは異なり、ファックスリレーではT.30ファックストーンが特定のHDLCフレームに分割（復調）され、ファックスリレープロトコルを使用してその情報がVoXネットワーク経由で送信され、相手側でビットがトーンに変換されます（変調）。

    両端のファックス機器ではトーンの送受信が行われていますが、どちらでも復調と変調のファックス リレー プロセスは意識されていません。

    CiscoファックスリレーおよびT.38ファックスリレーも、T.37ファックスストアアンドフォワードとは異なります。T.37では、VoIPゲートウェイで次の受信を可能にする標準ベースの方式が提供されます。

    現在、ほとんどのCisco音声ゲートウェイでは、IPネットワークを介してファックストラフィックを送信するために、次の2つの方法がサポートされています。

    1. ファックス パススルー：ファックス パススルー モードでは、ファックス コールと音声コールはゲートウェイでは区別されません。

    2. Cisco ファックス リレー：ファックス リレー モードでは、T.30 ファックス シグナリングはゲートウェイで終端されます。

    CiscoファックスリレーおよびT.38ファックスリレーも、T.37ファックスストアアンドフォワードとは異なります。T.37では、VoIPゲートウェイで次の受信を可能にする標準ベースの方式が提供されます。

    • FAX機器から送信されたファックスを、 SMTP のメール サーバに転送します。メール サーバでは、受信したファックスをユーザに電子メール メッセージとして配信できます。

    • メール サーバからの電子メール メッセージを、通常のファックス機器で受信できるようにファックス信号に変調します。

    次の図に VoX ネットワークを経由するファックス リレーを示します。発信元と終端のゲートウェイへのファックス接続は、ゲートウェイ上の FXS ポートに直接接続できます。あるいは、PBX または PSTN 経由で、ゲートウェイ上の E1、Basic Rate Interface（BRI; 基本速度インターフェイス）、FXO、または E&M ポートに接続できます。

    20227-faxrelay-tsguide2

    設定に関する考慮事項

    Cisco 3810、2600、3600、5300 などの VoIP、VoFR、VoATM の各プラットフォームでは、ファックス リレーがデフォルトでオンになっています。2台のルータ間で音声コールが正常に完了した場合は、ファックスコールが正常に動作するはずです。しかし、ファックスリレーが動作しない場合やパフォーマンスを改善する必要がある場合は、問題をトラブルシューティングするために先行して発行できるファックスリレー固有のコマンドがいくつかあります。

    fax rate コマンド

    fax rate コマンドは、VoFR または VoIP ダイヤルピアに設定モードで設定します。デフォルトの設定は fax rate voice であり、この設定は各ダイヤルピアの設定上は表示されません。

    fax rate コマンド 
    vnt-3660-23(config-dial-peer)#fax rate ?
  12000    FAX   12000 BPS
  14400    FAX   14400 BPS
   2400    FAX   2400  BPS
   4800    FAX   4800  BPS
   7200    FAX   7200  BPS
   9600    FAX   9600  BPS
  disable  Disable Fax Relay
  voice    Highest possible speed allowed by voice rate

    fax rate voice の設定では、ファックス レートがコーデックの帯域幅に制限されます。つまり、ダイヤルピアが音声を 8 kbps に圧縮するデフォルトの G.729 音声コーデックを使用するように設定されている場合、ファックス コールがこのコーデック帯域幅を超えることが、この fax rate voice 設定により許可されないということを意味しています。

    ファックスが最初に 14400 bps または 9600 bps の高い帯域幅でネゴシエートを試みても、ファックスの帯域幅は 7200 bps に制限されます。

    PSTN 経由で接続していたときには、ある一定時間以内で処理を完了していたファックスが、今では 2 倍の時間がかかる、という不満がよくあります。帯域幅の狭い G729 などのコーデックがデフォルトの fax rate voice とともに設定されている場合は、このような動作が予想されます。

    fax rate コマンドを使用して、コーデック圧縮よりも広い帯域幅を使用するようにファックス送信を設定できます。

    fax rate 14400 コマンドにより、設定された音声コーデックに関係なく、ファックス コールを最大 14400 bps にネゴシエートできます。この設定により、完了時間が長くなる問題が解決します。

    VoX ネットワーク内で fax rate コマンドを使用する主な目的は、コールごとに確定的な帯域幅を適用することにあります。

    fax rate voice がデフォルトで設定されているのは、VoX ネットワーク内で音声コールとファックス コールの両方に確実に同じ量の帯域幅が使用されるようにするためです。この考慮事項は、ファックスレートがコーデック帯域幅よりも大きい値に変更された場合に理解できます。

    さらに、ファックス機器によっては、デフォルト以外のレートでの方が動作が安定する可能性があります。この場合、さまざまな速度で動作をテストするのに、fax rate コマンドを使用できます。

    ルータの出力を見て、fax rate コマンドを発行すると、ファックス リレーを無効にすることも可能なことに注意してください。ファックス リレーをディセーブルにし、G711 などの高帯域幅コーデックを設定することは、有効なトラブルシューティングのテクニックです。

    このテクニックについては、6の「トラブルシューティング」セクションを参照してください。ファックス リレーをディセーブルにして、コーデックをパススルーに変更.

    fax-relay ECM disable コマンド

    fax-relay ECM disable コマンドは、Cisco 独自のファックス リレーでのみ利用可能で、ペアのファックス機器間で Error Correction Mode（ECM; エラー訂正モード）ネゴシエーションをディセーブルにするために発行します。

    ECM はエラーなしでファックス送信するもので、普通は比較的上位の機種に見られる機能です。

    残念ながら、ECM はジッタとパケットロスに対する許容度が低い（およそ 2 %）のですが、このネゴシエート機能がイネーブルになっている場合は、パケット損失が起こりやすい VoX ネットワークではファックスの障害率が高くなるという結果になる可能性があります。終端のファックスで出力結果が不完了になるのは、パケット損失による障害の症状です。

    両方のファックス機器がファックスのネゴシエーション フェーズ中に合意すると、ECM がイネーブルになります。しかし、ファックス リレーの場合は、ルータによりファックス トーンを正しい HDLC フレーム形式に復調されます。

    その結果、ルータは ECM ステータスを示すフレーム内のフィールドを捕捉し、上書きすることができます。「ECM 機能を備えている」ことをファックス機器が送信しても、ルータは他のファックス機器が「ECM がサポートされていない」と判断するようにこのパラメータを変更できます。

    次に、両方のファックス機器で ECM が強制的にディセーブルにされ、それは標準の T.4 データでファックス データが送信されるということを意味します。

    ECM を無効にすると、パケット損失（およそ 10 %）やディレイの率がかなり高い場合であっても、ファックスの信頼性が大幅に向上します。さらに、このコマンドを使用すると、パケット損失の隠蔽と呼ばれる Cisco IOS の機能が自動的にイネーブルになります。この機能によって失われたスキャン行が反復され、ファックス機器ですべてのデータを受信していると判断されるように装うことができます。

    ECMを使用すると、パケット損失の起こりやすいVoXネットワークでのファックス送信の成功率を向上できますが、基本的なネットワークの問題は残っており、他の問題が発生する前に対処する必要があります。

    VoIP ダイヤルピアの下で実行する簡単な設定ステップは、ECM をディセーブルにすることです。コマンド リファレンスで説明されているように、このコマンドは現在、VoIP ダイヤルピアでのみ動作します。VoFR と VoATM でも設定は可能ですが、ECM はディセーブルになりません。

    fax-relay ECM disable コマンド 
    vnt-3660-23(config-dial-peer)#fax-relay ECM ?
disable Disables ECM mode for fax relay

    fax NSF コマンド

    fax NSF コマンドは、独自のファックス機能の転送を防ぐために使用します。ルータのファックスリレー実装は、T.30仕様に基づいてファックストーンを復調および復号化するため、独自のトランザクションまたは符号化によってファックスリレーが中断され、ファックス送信が失敗します。特定のメーカーのファックス機器では、拡張機能が使用可能であることがこれらの独自の符号化を使用して通知されますが、これはファックス ベンダーが自社と他社製品を区別するのに有効です。この機能の通知は、オプションの Non Standard Facilities（NSF）フィールドを使用して、ファックス ネゴシエーション中に実行されます。

    fax NSFコマンドを発行すると、ルータではNSFが上書きされ、標準のファックストランザクションのみが実行されます。ベンダー固有の機能のうち、標準のGroup 3の要件を超えるものや、Ciscoファックスリレーを中断させるものは使用できません。通常、このコマンドを発行するとNSFはすべて0に設定され、NSFフィールドによって発生する問題が修正されます。

    fax NSF コマンド 
    vnt-3660-23(config-dial-peer)#fax NSF ?
 WORD  Two-digit country code + four-digit manufacturer code
vnt-3660-23(config-dial-peer)#fax NSF 000000

    fax protocol コマンド

    VoIPで使用するファックスリレープロトコル（T.38またはCiscoファックスリレー）を指定するには、fax protocolコマンドが必要です。

    fax protocol コマンド 
    vnt-3660-23(config-dial-peer)#dial-peer voice 3 voip
vnt-3660-23(config-dial-peer)#fax protocol ?
cisco   Use Cisco proprietary protocol
system  Use choice specified in global fax protocol CLI
t38     Use T.38 protocol

    cisco オプションにより、Cisco ファックス リレーが設定されます。t38 オプションでは、Cisco ファックス リレーがディセーブルにされ、T.38 がイネーブルにされます。Cisco 5350 や 5400 など一部の音声プラットフォームでは、T.38 だけがサポートされています。相互運用性に関して、Cisco ファックス リレーがデフォルトになっているプラットフォームでは、T.38 を明示的に設定する必要があります。system オプションによって、ダイヤルピアでは voice service voip コマンドでグローバルに設定されているファックス リレー プロトコルを受け継ぐことができます。voice service voip コマンドで何も設定されていない場合は、Cisco ファックス リレーがデフォルトになります。

    fax protocol コマンドのデフォルト設定は、system オプションです。systemオプションのデフォルトはCiscoファックスリレーであるため、グローバルに何も明示的に設定されていない場合、VoIPダイヤルピアは常にデフォルトのCiscoファックスリレーになります。

    fax protocol コマンド 
    <snip>

!
voice service voip
!

!--- Note that there is no fax protocol configured so the !--- default is Cisco fax relay. Any dial-peer that points !--- here uses Cisco fax relay as the fax protocol.

<snip>

!
dial-peer voice 3 voip
destination-pattern 1000
session target ipv4:10.1.1.1
!

!--- Note that because fax protocol is not configured under !--- this VoIP dial-peer, the default is fax protocol system, !--- which automatically tells this dial-peer to inherit the !--- fax configuration from voice service voip above.

<snip>

    トラブルシューティング

    VoIP、VoATM、および VoFR でのファックス リレーに関わる主要な問題を解決するために、次のステップを紹介しています。特定のカプセル化タイプまたはファックスリレータイプに固有の情報が記録されます。

    1. 問題の特定と切り分け

    ファックス リレーの問題のトラブルシューティングを行うときは、最初に問題を最も簡単なかたちに限定することから始めます。問題の多くは、複数のファックス機器がファックス トラフィックを送受信できない状況で発生します。問題のある 2 台のファックス機器を切り分けて、単純なトポロジに注力するのが最も簡単な方法です。これらの機器がどのように相互に接続しているのかを判断し、この 2 台の間で先に問題を解決します。また、トポロジの全体像を描き、ファックス機器がどのように相互接続されているかを判断することをお勧めします。

    一度に 1 つの問題を処理することにより、混乱を最小限にして、秩序立ったトラブルシューティングが可能になります。また、この問題の解決策によって、ネットワーク内の他のファックスリレーの問題が解決される場合もあります。ファックス リレーに関する問題のほとんどは、VoX の設定やネットワークの設計が不十分であることに起因します。これらが原因となって、基本的な接続性や物理回線に関する問題、あるいはパケット損失やジッタの問題が発生します。

    問題の特定と切り分けを行ったら、次のステップでは VoX の基本設定を確認し、ネットワークの状態を監視します。

    2. 基本接続のチェック

    基本的なファックスの接続問題の要因としては、次のようなものが考えられます。

    1. 通常の音声接続に関する問題

      ファックスの接続性を調べる前に、通常の音声コールが実行できることを確認します。電話機が取り付けられていない場合は、ファックス機器を取り外して通常の電話機を接続します。通常の音声コールが接続しない場合は、VoX関連の問題である可能性があるため、ファクスのトラブルシューティングに進む前に、通常の音声接続の問題として問題のトラブルシューティングを行うことができます。

    2. ダイヤルピアに関する設定の問題には次のものがあります。

      • 照合するダイヤルピアが間違っている。

        音声コールが VoX ネットワークを通じて両方向で正常に実行できることを確認した後、show call active voice brief コマンドを発行し、音声コールごとに照合するダイヤル ピアを控えておきます。

        note-icon

        注：注：VoIPトランクがある場合は、show call active voice briefコマンドを使用してすべてのコールレッグを確認できます。Cisco IOS ソフトウェア リリース 12.2 の一部のバージョンでは、show call active コマンドにバグがあり、VoIP トランク経由で到着するファックス コールが表示されません。show call active fax brief コマンドを実行すると、これらのコールが表示されます。このバグの詳細については、Cisco Bug ID CSCdx50212 およびCisco Bug ID CSCdv02561を参照してください 。

        note-icon

        注：設定したダイヤルピアが、一致するピアであることを確認してください。次のコマンド出力では、発信 VoIP コール レッグがピア ID 100 を使用しています。

        show call active voice brief コマンド 
        ms-3640-13b#show call active voice brief

<snip>

Total call-legs: 2
1218 : 51710253hs.1 +415 pid:400 Answer 400 active
dur 00:01:08 tx:3411/68220 rx:3410/68200
Tele 3/0/0:43: TX:68200/6820/0ms g729r8 noise:0 acom:2
 i/0:-51/-44 dBm

1218 : 51710396hs.1 +272 pid:100 Originate 100 active
dur 00:01:09 TX:3466/69320 rx:3467/69340
IP 2.1.1.2:17092 rtt:56ms pl:64730/0ms lost:0/1/0
 delay:69/69/70ms
 g729r8

Total call-legs: 2

        ファックス リレー問題の一般的な原因として、正しく設定されたダイヤルピアが、照合するピアではない場合があります。また、終端のゲートウェイに特定の着信 VoIP ダイヤルピアが設定されておらず、Cisco IOS ソフトウェアが最初の適切な VoIP ダイヤルピア（デフォルトを含む）を着信ダイヤルピアとして選択することもよくあります。この着信ダイヤルピアのパラメータは、発信元ゲートウェイの発信ダイヤルピアのパラメータと一致しない可能性があります。

        発信および着信 VoIP ダイヤルピアの設定が、常に同じである必要はありません。しかし、ファックス リレーの問題があるときは、専用の着信 VoIP ダイヤルピアが終端側のルータにあり、その設定が発信元ルータの発信 VoIP ダイヤルピアの設定と一致することを確認してください。ISDN 接続されたルータ用の次の設定は、宛先パターン「5...」が、発信元ゲートウェイでの発信側、終端ゲートウェイでの着信側に一致する具体例です。

        発信元ゲートウェイ 終端ゲートウェイ 
        !--- Incoming POTS peer:

Dial-peer voice 1 pots
Incoming called number.
Direct-inward-dial
Port 1/0:15

!--- Outgoing VoIP peer:

Dial-peer voice 2 voip
Destination-pattern 5…
Session target ipv4:10.10.10.10
Fax rate 14400
fax protocol t38
 ls-redundancy 0
 hs-redundancy 0

        !--- Outgoing POTS peer
:
Dial-peer voice 10 pots
Destination-pattern 5…
No digit-strip
Port 2/0:15

!--- Incoming VoIP peer:

Dial-peer voice 20 voip
Incoming called-number 5…
Fax rate 14400
fax protocol t38
 Ls-redundancy 0
 Hs-redundancy 0

        着信および発信の両方で照合されるダイヤル ピア、VoIP、および POTS の詳細は、『ボイス - Cisco IOS プラットフォームにおける着信および発信ダイヤル ピアの照合方法について』を参照してください。

        ダイヤル ピアの一致をチェックする別の方法として、debug voip ccapi inout コマンドを発行する方法があります。このコマンドからのデバッグ出力は、ssaSetupPeerメッセージを示し、着信番号に一致するすべてのダイヤルピアをリストします。ccCallSetupRequest メッセージには、選択された発信 VoIP ダイヤルピアを示す発信ピア オプションが付け加わっています。同じ宛先に対して複数のVoIPダイヤルピアが設定されている場合、最初のコール設定が失敗し、別のダイヤルピアが試行される可能性があります。この場合、別のccCallSetupRequestがデバッグに表示されます。

        debug voip ccapi inout：発信元ゲートウェイ 
        .Jun 4 21:06:43.461: ssaSetupPeer cid(19)
 peer list: tag(400) called number (5074)

.Jun 4 21:06:43.461: ccCallSetupRequest
 (Inbound call = 0x13, outbound peer =100,
  dest=, params=0x62F1CC70 mode=0, *callID=0x62F1CFD8,
  prog_ind = 0)

        終端の音声ゲートウェイでは、debug voip ccapi inout(ind)コールトレースの最初の行に（ここに示すように）、終端ゲートウェイの着信VoIPダイヤルピアを示すpeer_tagオプションの付いたcc_api_call_setup_indメッセージがあります。

        debug voip ccapi inout：終端ゲートウェイ 
        .Jun 4 21:06:43.461: cc_API_call_setup_ind
 (vdbPtr=0x62F07650,
 callInfo={called=5074,called_oct3=0x80,
 calling=5075, calling_oct3=0x0,>calling_oct3a=0x83,
 calling_xlated=false,
 subscriber_type_str=Unknown,fdest=1,
 peer_tag=400, prog_ind=0},callID=0x635F72D0)

      • 一方または双方のゲートウェイのダイヤルピア設定が間違っている。

        正しいダイヤル ピアが照合されていることを確認したら（この場合、発信元ゲートウェイではダイヤルピア 100、着信ルータではダイヤルピア 400）、そのダイヤルピアがファックス用に正しく設定されていることを確認します。コールの両側で確認する一般的なエラーには、次のものがあります。

        • 低帯域幅のコーデックが使用されているにもかかわらず、ファックス リレーが無効になっています（つまり、ダイヤルピアで fax rate disable コマンドが発行されています）。

        • 一方の音声ゲートウェイのダイヤルピアはCiscoファックスリレー用に設定されていますが、他方の音声ゲートウェイはCisco 5350/5400です。Cisco 5350/5400ではT.38だけがサポートされているため、ネゴシエーションは失敗します。

        • 終端ゲートウェイの着信ダイヤル ピアとして使用されているデフォルトのダイヤル ピアとそのデフォルトのパラメータが、発信元ゲートウェイの発信ダイヤル ピアと一致していません。

      • コンパンディング タイプが正しくない。

        米国のコンパンディングタイプはµ-lawで、ヨーロッパとアジアの場合はa-lawです。show voice call コマンドを発行して、現在どちらのタイプが設定されているかを確認できます。BRI ポートまたは E1 ポートでは、ルータの圧縮伸長タイプが接続先装置の圧縮伸長タイプと一致しない場合、コールが失敗したり接続したりしますが、音声が極端に歪むために人間の耳で聞き取れなくなったり低音のノイズが発生したりします。

        Cisco IOS ソフトウェア リリース 12.2(3) では、compand-type コマンドが BRI ポートにないため、コンパンディング タイプはデフォルト値になります。このバグの詳細については、Cisco Bug ID CSCdv00152およびCisco Bug ID CSCdv01861を参照してください。

    3. ダイヤル ピアに関係しない、その他の基本接続に関する問題には次のものがあります。

      • ゲートウェイ ペア同士の Cisco IOS ソフトウェアに互換性がない。

        対向ゲートウェイの Cisco IOS ソフトウェア リリースが常に一致する必要はありませんが、問題が起きる場合は、そのリリースをチェックすることを推奨いたします。

      • Compressed Real-Time Transport Protocol（cRTP）。

        cRTP に関わるいくつかの既知の問題があります。これらの問題については、修正が利用できます。問題が発生したときに、Cisco IOS ソフトウェアのアップグレードが適切な措置であるか調べるために、cRTP をディセーブルにすることは理にかなっています。

      • Cisco AS5300 音声ゲートウェイでは、VCWare と Cisco IOS ソフトウェアに互換性があることを確認する。

    4. PSTN 経由でのファックス接続の問題

      音声コールは両方向で正常に動作するにもかかわらず、ファックス コールが少なくとも一方向で失敗する場合、これら 2 台のファックス機器で PSTN 経由で通常のファックス通信を行えるかどうかをチェックします。つまり、ファックス機器が VoX ネットワークを経由せず、PSTN で相互にファックスを正常に送信することを確認します。正常に動作しない場合は、ファックス機器自体に問題のある可能性があり、ファックス リレーの問題について考慮する前に対処する必要があります。

    3. デジタル インターフェイスでのスリップなどのエラーのチェック

    ファックス リレーを実行しているルータで T1 または E1 のデジタル接続が使用されている場合は、それらの接続でエラーがないことを確認します。デジタル インターフェイスの場合、ファックス リレーはエラー、特にスリップに対して非常に敏感です。このエラーは音声コールでは目立ちませんが、ファックスが失敗する原因になる可能性があります。

    show controller T1(E1) 1/0 コマンド 
    vnt-3660-23c#show contr t1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20010805, FPGA: 15
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
Data in current interval (132 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs,
0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
 0 Unavail Secs

    発信ゲートウェイと終端ゲートウェイの両方のT1またはE1コントローラには、通常、エラーはありません。エラーが発生した場合は、コール内でshow controller(T1、E1、および1/0 varies)コマンドを数回繰り返して、エラー数が増加するかどうかを確認します。スリップの最も一般的な問題は、クロッキング エラーを引き起こす同期の問題です。

    パケット音声ネットワークでは、通常はルータで回線からのクロックが使用されていることを確認すれば十分です。そうではない場合は、clock source line コマンドがコントローラ レベルで入力されていることを確認します。しかし、VoATM または TDM ネットワークでは、クロッキング階層が確立されていて、ルータがネットワークを通してクロックを渡す必要があり、さらに考慮事項が必要になります。『クロッキング計画』のドキュメントでは、同期クロッキングについての詳細が説明されています。

    26xxまたは366xルータでAIM VOICEカードを使用すると、network-clock-participateおよびnetwork-clock-selectコマンドを追加しない限り、コントローラには「制御スリップ」が表示されます。

    Cisco MC3810 プラットフォームでは、network-clock-select コマンドを設定し、show network-clock コマンドを発行して、設定が有効になったことを確認する必要があります。

    Cisco 7200VXR プラットフォームでは、音声カードに対して frame-clock-select コマンドの設定が必要です。このコマンドは特に 7200VXR 音声ゲートウェイの場合に重要です。これは、デフォルトでは内部の TDM バスがローカル オシレータによって動作していないためです。通常、E1トランクはテレフォニーネットワークと同期されているため、クロッキングエラーが見えなくなり、ファックス送信が断続的に問題になります。詳細は、Cisco Bug ID CSCdv10359を参照してください。

    C4224 MFT カードでは、ラインからクロックが受け入れられる際に、コントローラ t1 x/y の下で、clock source loop-timed コマンドを発行する必要があります。この設定により、システム全体のクロックから、コントローラ クロックが切り離されます。それから、network-clock-select コマンドの設定が必要になります。この場合、network-clock-select 1 t1 x/y のようになります。

    4. ファックス インターフェイスタイプのチェック

    Cisco 3660、5300、5350、5400、および 5800 などの一部のプラットフォームでは、ルータのデフォルト設定が fax interface-type modem になっています。fax interface-type modem グローバル設定コマンドにより、ファックス コールは強制的にモデム（通常は T.37 ストア アンド フォワード ファックス）に送られ、DSP には送られません。Cisco ファックス リレーを動作させるためには、ファックス コールが DSP に送られる必要があります。つまり、fax interface-type vfc コマンドを設定する必要があります。

    fax interface-type コマンド 
    vnt-3660-23c(config)#fax interface-type ?
modem Use modem card
vfc   Use Voice Feature Card

vnt-3660-23c(config)#fax interface-type vfc
You must reload the router

    ルータをリロードしてください。リロードしないと、コマンドは有効になりません。Ciscoファックスリレー（またはT.38）を使用しているプラットフォームではファックスコールが失敗するため、このコマンドは確認する必要があります。

    fax interface-type vfc コマンドは、12.2 よりも前の Cisco IOS ソフトウェア リリースでは必要ありませんでした。この問題は、音声ゲートウェイのいずれかを Cisco IOS ソフトウェア リリース 12.2 以降にアップグレードした場合によく見られます。

    5. ファックス コール中にファックス コーデックがロードされていることを確認

    ファックス ネゴシエーション フェーズが完了すると、各ファックス機器の LCD 画面にリモート ファックス機器の ID が表示されます。ファックス コーデックを正常にダウンロードできなかった場合、ファックス機器同士がネゴシエーションを完了できる可能性は低くなります。一方で、リモートのファックス機器 ID が表示されない場合は、このエリアについてさらにデバッグを行うことが適切です。

    音声ゲートウェイがファックス送信を検出してファックス コーデックを正常にロードしたことを確認するには、2 つの方法があります。

    1. debug vtsp all コマンドおよび debug voip ccapi inout コール トレースを発行します。これらのデバッグについては、このドキュメントの「デバッグ」セクションで説明しています。

    2. show voice trace コマンドを発行します。show コマンドは debug コマンドよりもルータでのリソースの消費が少なく、実際に運用しているネットワークにおいては適しています。次は ISDN インターフェイスでの show voice trace コマンドからの出力例です。

    show voice trace コマンド 
    BrisVG200gwy01#show voice trace 1/0:15
1/0:15 1
1/0:15 2
1/0:15 3
1/0:15 4
1/0:15 5
1/0:15 6
1/0:15 7
1/0:15 8
1/0:15 9
1/0:15 10 State Transitions: timestamp (state, event) -> ...
63513.792 (S_SETUP_REQUEST, E_TSP_PROCEEDING) ->
63515.264 (S_SETUP_REQ_PROC, E_TSP_ALERT) ->
63515.264 (S_SETUP_REQ_PROC, E_CC_BRIDGE) ->
63515.332 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.332 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63515.348 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.348 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63515.356 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.356 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63518.656 (S_SETUP_REQ_PROC, E_CC_REQ_PACK_STAT) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_VP_DELAY) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_VP_ERROR) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_RX) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_TX) ->
63521.028 (S_SETUP_REQ_PROC, E_CC_REQ_PACK_STAT) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_VP_DELAY) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_VP_ERROR) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_RX) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_TX) ->
63524.128 (S_SETUP_REQ_PROC, E_TSP_CONNECT) ->

!--- Fax tone detected:

63529.352 (S_CONNECT, E_DSP_TONE_DETECT) ->
63529.356 (S_LFAX_WAIT_ACK, E_PH_CODEC_ACK) ->

!--- Fax codec being downloaded to DSPs:

63529.356 (S_LFAX_DOWNLOAD, E_pH_CODEC_FAX) ->
63529.356 (S_LFAX_DOWNLOAD, E_DSPRM_PEND_SUCCESS) ->

    6. ファックス リレーをディセーブルにして、コーデックをパススルーに変更

    これまでのステップで、音声コールが動作すること、ファックスが PSTN 経由で動作すること、およびファックス リレー パス中のすべてのデジタル インターフェイスがエラーなしで動作することが確立されています。この手順では、ファックス リレーを無効にした状態でファックス通信ができるかどうかを確認します。VoIP、VoATM、VoFR ダイヤルピアの下で、次を入力します。

    fax rate disable コマンド 
    vnt-3660-23(config)#voice-port 2/0:15
vnt-3660-23(config-voiceport)#no echo-cancel enable
vnt-3660-23(config)#dial-p voice 3
vnt-3660-23(config-dial-peer)#fax rate disable
vnt-3660-23(config-dial-peer)#codec g711ulaw
vnt-3660-23(config-dial-peer)#no vad

    これらのコマンドは必ず発/着 両側のゲートウェイで入力します。これらのコマンドは、ファックス リレーを無効にし、エコー キャンセルを無効にして、VAD を使用しない広帯域幅のコーデックを強制的に使用します。次にルータでは通常の音声コールのようなトーンがサンプリングされますが、高帯域幅のコーデック（G.711）を使用して、可能なかぎり最も正確なサンプルがキャプチャされます。相手側で再生されるトーンは、できるだけ正確です。この手順で注意が必要なのは、G.711は64 kbps帯域幅コーデックであるため、トランスポートプロトコルのオーバーヘッドが追加されると、コールごとに最大80 kbps（VoIPの場合）消費されることです。

    このテストが成功した場合は、2 つのことが確定します。1 つめとして、コールごとの帯域幅使用量がネットワークの主な問題でない場合、ファックス リレー問題に対して潜在的なファックス パススルーの回避策があります。次に、より重要な点として、帯域幅の消費が問題となる場合、問題はファックスリレーソフトウェアに切り分けられ、TACケースがオープンされます。

    このテストが失敗する場合、ファックス リレーによるファックス コールの失敗原因が、このテストの失敗原因でもあるとも考えられます。まず考えられることは、ネットワークで大量のジッタやパケット損失が発生している可能性があることです。

    7. VoX ネットワークでのパケット損失のチェック

    次の手順は、パケット損失があるかどうかを判断する最も簡単で正確な方法です。

    1. VoX ダイヤルピアで VAD を無効にします。

    2. ファックス機器が接続されているのと同じポート間で音声コールを行います。（ファックス機器は通常の電話機として利用できます。あるいは、ファックス機器が接続されているのと同じポートに受話器を接続できます。）

    3. コールが接続されたら、次を実行します。

      1. show voice dsp コマンドを発行します。DSP チャネルの 1 つが設定したコーデックをロードしていることがわかります。通常は、「TX/RX-PAK CNT」カラムで送信と受信のパケット カウンタが等しくなります。これは、パケットが失われていないことを示しています。カウンタが等しくない場合、パケットが失われる可能性があります。show voice dsp コマンドを 30 秒間隔で何回か入力し、差が大きくなってパケットが失われているかどうかを判断してください。

      2. show voice call summary コマンドを発行して、どのポート（および、該当する場合はタイムスロット）が音声コールに割り当てられているのかを確認します。terminal monitor と入力した後、音声ポート（および該当する場合はタイムスロット）を指定して show voice call コマンドを発行し、詳細な DSP 統計情報を取得します。出力の「***DSP VOICE VP_ERROR STATISTICS***」のカウンタを確認してください。通常は0または20未満です。20 を超えるカウンタが 1 つ以上ある場合は、パケット損失について調査の必要があります。

    ネットワークでパケット損失が起こりやすいと思われる場合は、ファックス リレーの確実な動作を期待できません。ECM をディセーブルにすることは可能ですが、QoS がエンドツーエンドで確実にプロビジョニングされるようにして、音声とファックス リレーのトラフィックが優先され、輻輳時にパケットが失われないようにするために、さらに調査を進める必要があります。「関連情報」セクションには、音声品質の問題に関するトラブルシューティングの方法についての詳細が説明されています。

    8. ファックス リレー ECM をディセーブルにする（Cisco 独自の VoIP のみ）

    パケット損失および大量のジッタがあるネットワークでは、ECM をディセーブルにしてファックス リレー コールを改善します。fax-relay ECM disable コマンドを発行して（詳細はこのドキュメントの「設定に関する考慮事項」セクションで説明）ECM をオフにすると、さらに大きいジッタやパケット損失を許容できます。

    fax-relay ECM disable コマンドを発行すると、パケット損失の起こりやすいネットワークでファックス リレーのパフォーマンスが改善されますが、基本的なトラブルシューティングを行う場合にも、このコマンドの使用を推奨します。ネットワークにおいてジッタに関して目に見える問題が発生していなくても、このコマンドはファックス リレーの問題を特定するのに役立つことがあります。このコマンドは VoFR および VoATM ダイヤルピアで使用できますが、現在は VoIP のみで動作します。

    注：このコマンドを実行すると、パケット損失の隠蔽機能もアクティブになります。

    fax-relay ECM disable コマンド 
    vnt-3660-23(config-dial-peer)#dial-peer voice 3
vnt-3660-23(config-dial-peer)#fax-relay ECM disable

    9. T.38 パケット冗長性をイネーブルにする（T.38 VoIP のみ）

    VoIP 対応の T.38 がファックス リレー プロトコルとして使用されている場合は、両方のゲートウェイ上の適切なダイヤル ピアで次のコマンドを設定することにより、T.38 パケット冗長性機能をオンにできます。

    T.38 パケット冗長性 
    vnt-3660-23(config-dial-peer)#fax protocol t38 
 Ls-redundancy X Hs-redundancy Y

    X > 0、Y = 0 とします（Ls-redundancy だけに変更を加えます）。

    Cisco 独自のファックス リレーを使用している場合は、ECM をディセーブルにするための代替または追加のオプションとして、ファックス リレー プロトコルを T.38 に変更し、T.38 パケット冗長性機能をテストできる方法があります。この機能によってパケット損失に起因する障害を軽減できますが、T.38 パケット冗長性では帯域幅使用量が大幅に増えるため、できるだけパケット損失をなくすことが望まれます。

    10. fax NSF コマンドをすべて 0 に設定

    独自の符号化を使用するために、ファックス ネゴシエーション中に NSF フィールドを変更する特定のメーカーのファックス機器では、fax NSF コマンドが役に立つ場合があります。このコマンドを使用すると、独自の符号化を実装しようとするファックス機器によって行われた設定に対して、ファックス リレーを実行するルータが設定を上書きできます。fax NSF コマンドが利用できるようになる前は、このようなメーカーのファックス機器では、ファックス リレーが失敗することがありました。通常、fax NSF コマンドは、NSF フィールドをすべて 0 に設定し、両側から標準のファックス ネゴシエーションを強制するために使用されます。このコマンドは、Harris や Lanier などのメーカーの機器に対して有効であることが確認されており、ファックス リレーが失敗する場合の使用を推奨します。

    fax NSF コマンド 
    vnt-3660-23(config-dial-peer)#fax NSF 000000

    11. MGCPゲートウェイがFXRパッケージ用に設定されているかどうかを確認する

    PSTNからファクスサーバへのT.38ファクスコールが失敗し、Cisco Unified Communications Managerトレースにsupport_FXR=0と表示されている場合、MGCPゲートウェイからFXRパッケージ設定が欠落している可能性があります。この場合、MGCPゲートウェイに次のコマンドを追加します。

    no mgcp fax t38 inhibit
mgcp package-capability fxr-package
mgcp default-package fxr-package

    その後、ゲートウェイをリセットすると、ファックスコールが動作を開始します。

    12. 解決の最終段階

    上記のトラブルシューティング手順でファックスリレーの問題が解決しなかった場合は、より高度なトラブルシューティングが必要になる可能性があります。Cisco Technical Assistance Center（TAC）のサービスリクエストを開く前に、次の追加手順を試みてください。

    • 障害が発生しているファックス機器のメーカーとモデルを確かめ、それらに関する既知の問題がないかを調べます。

      ときどき、特定のメーカーのファックス機器についての問題を取り上げている サービスリクエストや不具合が存在します。たとえば、Bug Search Tool（登録ユーザ専用）でPitney Bowesファックスを検索すると、Pitney Bowesファクス機とCiscoファクスリレーに不具合があることが分かります(Cisco Bug ID CSCdu78373（登録ユーザ専用）)。これは Cisco IOS ソフトウェアのバグではなく、両端のファックス機器が Pitney Bowes 9920 シリーズまたは 9930 シリーズである場合に Pitney Bowes の専用ファックス シグナリング プロトコルに互換性がないことから起こるバグです。この不具合を回避するには、ファックス機器の専用プロトコルを無効にします。またはファックス リレーを無効にして、より広い帯域幅のコーデックを使用します。

      既知の警告

      既知の警告とは、製品のソフトウェアリリースでの予期せぬ動作や障害です。この表には、Cisco 音声ゲートウェイでのファックス サポートについて、既知の問題に関する情報が示されています。

      CCOアカウントをお持ちの場合は、Bug Search Toolと呼ばれるCisco Bug Trackerシステムツールで既知の問題を検索できます。Bug Search Toolにアクセスするには、次のいずれかのタスクを実行します。

      表 1 既知の警告

      Bug ID 要約 説明
      CSCdu30250 VAD により、ファックス パススルー モードで重大なエラーが発生します。 Cisco音声ゲートウェイがファックスパススルーモードに設定されている場合、ファックスコールに関連付けられたすべてのVoIPダイヤルピアで音声アクティビティ検出(VAD)を無効にします。VoIP ダイヤルピアの VAD をディセーブルにするには、これらのコマンドを使用します。 
      config terminal
dial-peer voice XXX voip
no vad
      CSCdu62269 CSCdu62269 ゲートウェイ モードで、ファックス リレー コール（ペイロード タイプ 96 を使用する RTP パケット）を WS-X4604-GW へ開始すると、どの Cisco ゲートウェイ デバイスも失敗します。これは、12.1.5YF3 で解決されています。ゲートウェイ モードに設定されると、ソフトウェアではペイロード タイプ 96 と識別され、パススルーモードが開始されます。
      CSCdv08143 VG248 からゲートウェイ モードの WS-X4604-GW へのファックス パススルー モードでは、5 ～ 30 ページのファックス送信が失敗します。 この障害は、WS-X4604-GW 上のソフトウェア イメージ 12.1.5YF2 でのみ発生します。このエラーを防ぐには、12.1.5YF1、12.1.5YF3、あるいはそれ以降を使用してください。
      CSCdv83401 Cisco Catalyst 6000 スイッチでは、ファックスまたはモデム トーンが検出されると、コールは 10 ミリ秒（134 バイト）パケットでファックス パススルー モードに切り替わります。 ファックスパススルーモードのフレームサイズは214バイトです。ファックスは、パケット サイズが正しくない場合でも失敗しません。
      CSCdv83337
      CSCdw07735 WS-X4604/VIC-2FXS（のみ）から、Cisco CallManager 3-1-2c_spA ロード A00203010026 を使用する WS-X6624-FXS ゲートウェイへのファックス パススルーモードでは、ファックス送信が失敗します。WS-X4604/VIC-2FXS では、ゲートウェイおよびトール バイパス モードの両方でこの失敗が見られます。 この障害は、WS-X4604-GW上のソフトウェアイメージ12.1.5YF2および12.1.5YF3で発生し、12.2(7)Xソフトウェアで修正されています。
      CSCdw07804 ファックス送信は、WS-C4224V/VIC-2FXS（のみ）から、Cisco CallManager 3-1-2c_spA ロード A00203010026 を使用する WS-X6624-FXS ゲートウェイへのファックス パススルーモードで失敗します。 この障害は、WS-C4224Vのソフトウェアイメージ12.1.5YE2および12.1.5YE4で発生し、12.2(7)Xソフトウェアで修正されています。

    • 問題が発生する Cisco IOS ソフトウェア リリースで、ファックスに関する既知の問題がないか検索ツールを使用して探します。

      前のステップでは、特定のファックス メーカーと Cisco ファックス リレーのコードの間で既知の問題を識別するために、特定のファックス メーカーについて検索を行いました。次に、インストールされているCisco IOSソフトウェアリリースにファックスリレーの不具合がある可能性があるため、一般的な検索を実行します。

      たとえば、VoFR を使用するファックス リレーが Cisco IOS ソフトウェア リリース 12.1(2)T で動作しない場合は、Cisco.com の Bug Toolkit を使用して不具合を検索できます。この例では、次の値を使用します。

      • メジャーバージョン：12.1

      • リビジョン：2

      • 機能/コンポーネント：VoFR

      • キーワード： fax

      不具合の1つに、「fax doesnt work for vofr」というタイトルのCisco Bug ID CSCdr65984（登録ユーザ専用）があります。 この不具合により、VoFRではすべてのファックスリレーが失敗しました。この不具合が解消されたCisco IOSソフトウェアリリースにアップグレードする必要があります。

    • ハードウェア障害を除去します。

      場合によっては、問題の原因を 1 つずつ除外していくことで問題を切り分ける方が簡単なことがあります。異なるハードウェアの部品を交換して、ゲートウェイ間で代替の IP 接続を使用します。追加のハードウェアがある場合は、次のステップが役に立ちます。

      • 各ルータで異なるポートを使用する。

        E1 または T1経由で、PBX または PSTN と接続している ゲートウェイにおいて、FXS ポートも使用できる場合は、音声ゲートウェイの FXS ポートにファックス機器を直接接続してみてください。この手順は、E1カードの障害、テレフォニー側の問題、E1の同期またはケーブルの問題の可能性を排除して、問題をさらに切り分けるのに役立ちます。

      • 別のハードウェアで試す。

        FXS ポートを使用する別の音声ゲートウェイが利用できる場合は、イーサネット クロスケーブルを使用して各音声ゲートウェイに直接接続し、FXS ポートに接続されたファックス機器を使用してファックスを送信してください。この手順は、キューイング、フラグメンテーション、優先順位付けなどの問題がVoXネットワークに存在するかどうかを判別するのに役立ちます。

    • ルータで debug コマンドを使用して、問題を判別します。

      ファックス リレーの問題のトラブルシューティングに役立つ debug コマンドについての詳細は、次の「デバッグ」セクションを参照してください。

    デバッグ

    T.30 メッセージ

    通常のファックス送信中に起こるメッセージについて精通していない場合、デバッグを理解するのは困難になる場合があります。ここでは、1 ページのファックス送信で起こる、基本的な T.30 のトランザクションを図で示します。

    20227-faxrelay-tsguide3

    これらのトランザクションの詳細についての説明はこのドキュメントの範囲外ですが、ファックス リレー中に見られる基本的なトランザクションの定義について次に説明します。ここではクイック リファレンスとしてトランザクションをアルファベット順に列挙しています。また、Cisco ファックス リレーのデバッグでよく見られるメッセージを記載しています。このメッセージの詳細、またはここに記載されていないメッセージの詳細については、T.30仕様を参照してください。

    • CED（Called terminal identification）：ファックス コールへの応答時に終端側のファックス デバイスによって送信される 2100 Hz の信号。この信号は、接続上に存在してデータ送信のために準備している回線のエコー キャンセラを一時的に無効にします。

    • CFR（Confirmation To Receive）：以前のメッセージングとトレーニングが完了して、ファックス ページの送信が開始できることを確認する応答。

    • CNG（Calling Tone）：0.5 秒間オンの後、3 秒間オフとなる 1100 Hz のトーン。この信号により、ファックス端末が非音声デバイスとして識別されます。この信号では、開始側のファックス端末が、終端側のファックス端末からの DIS 信号を待機していることも示されます。

    • CRP（Command Repeat）：以前のコマンドがエラーで受信され、再送の必要があることを示す応答。(オプション)

    • CSI(Called Subscriber Identification)：呼び出されたファックス端末の固有のIDを国際電話番号で提供するために使用されます。(オプション)

    • DCN（Disconnect）：ファックス コールを終了しますが、応答を要求しません。

    • DIS（Digital Identification Signal）：呼び出されたファックス端末の機能を識別します。

    • DTC（Digital Transmit Command）：DIS 信号によって識別された機能への応答。ここで、発信側のファックス端末の機能と、着信側のファックス端末のDISメッセージで提供される機能とが照合されます。

    • EOM（End Of Message）：ファックス情報の完全なページの終わりを示します。

    • EOP（End Of Procedure）：ファックス情報の完全なページの終わりを示し、それ以上送信するページがないことを示します。ファックス コールの切断フェーズに進みます。

    • FTT（Failure To Train）：トレーニング信号を拒否して、再トレーニングを要求する際に使用します（再トレーニングは通常、より低い変調速度で行われます）。

    • MCF（Message Confirmation）：メッセージが正常に受信されたことを示します。

    • MPS（MultiPage Signal）：ファックス情報の完全なページの終わりを示し、受信側では次のページのための準備ができていることを示します。

    • NSF(Non-Standard Facilities):Tシリーズの仕様の範囲外である、特定の機能や要件を識別するために使用されます。(オプション)

    • RTN（Retrain Negative）：前のメッセージが正常に受信されなかったことを示します。次に進むには再トレーニングが必要です（通常はより低い変調速度で行われます）。

    • RTP(Retrain Positive)：完全なメッセージが受信されたことを示し、再トレーニング後にさらにメッセージが送信される可能性があることを示します。

    • TCF（Training Check）：トレーニングを確認するために（以前の T.30 信号方式で使用されていた 300 kbps の V.21 変調に対して）より高速な T.4 変調システムを通じて送信され、この速度でのファックス ページの送信が許容されることを示します。

    • TSI（Transmitting Subscriber Identification）：送信（発信）ファックス端末の ID を示します。(オプション)

    ファックス リレーの debug コマンド

    ファックス リレーで役立つ debug コマンドを次に示します。

    debug fax relay t30 all

    debug fax relay t30 all コマンドで、Cisco ファックス リレーのデバッグがイネーブルになります。

    debug fax relay t30 all コマンド 
    vnt-3660-23c#debug fax relay t30 all
Debugging fax relay t30

    これは、失敗したファックス リレー セッションからのデバッグのコピーです。これは Cisco IOS ソフトウェアリリース 12.2(7a) が稼働する、発信側ファックス ゲートウェイからのデバッグです。

    debug fax relay t30 all コマンドの出力 
    vdtl-3810-3b#
Dec 5 07:49:13.073: 1/2:62 1281347052 fr-entered (10ms)
Dec 5 07:49:17.985: 1/2:62 1281351950 fr-msg-det CRP
Dec 5 07:49:20.105: 1/2:62 1281354070 Fr-MSG-TX NSF
Dec 5 07:49:20.655: 1/2:62 1281354620 Fr-MSG-TX good crc,
 19 bytes
Dec 5 07:49:20.720: 1/2:62 1281354680 Fr-MSG-TX DIS
DEC 5 07:49:22.350: 1/2:62 1281356310 fr-msg-det TSI
DEC 5 07:49:23.045: 1/2:62 1281357000 fr-msg-det DCS
DEC 5 07:49:27.346: 1/2:62 1281361290 Fr-MSG-TX FTT
DEC 5 07:49:28.836: 1/2:62 1281362780 fr-msg-det TSI
DEC 5 07:49:29.531: 1/2:62 1281363470 fr-msg-det DCS
DEC 5 07:49:29.740: 1/2:62 1281363680 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:30.362: 1/2:62 1281364300 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:30.804: 1/2:62 1281364740 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:30.852: 1/2:62 1281364790 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:33.868: 1/2:62 1281367800 Fr-MSG-TX FTT
DEC 5 07:49:35.414: 1/2:62 1281369340 fr-msg-det TSI
DEC 5 07:49:36.113: 1/2:62 1281370040 fr-msg-det DCS
DEC 5 07:49:36.515: 1/2:62 1281370440 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:36.908: 1/2:62 1281370830 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:37.559: 1/2:62 1281371480 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:37.784: 1/2:62 1281371700 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:37.900: 1/2:62 1281371820 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:40.133: 1/2:62 1281374050 Fr-MSG-TX FTT
DEC 5 07:49:41.888: 1/2:62 1281375800 fr-msg-det TSI
DEC 5 07:49:42.583: 1/2:62 1281376490 fr-msg-det DCS
DEC 5 07:49:43.173: 1/2:62 1281377080 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:44.937: 1/2:62 1281378840 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:45.386: 1/2:62 1281379290 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:46.941: 1/2:62 1281380840 Fr-MSG-TX FTT
DEC 5 07:49:48.503: 1/2:62 1281382400 fr-msg-det DCN
DEC 5 07:49:50.631: 1/2:62 1281384520 fr-end-dcn

    このデバッグには、ファックス リレー内の DSP で発生する T.30 イベントが示されています。重要な点として、DSP とファックス デバイスとの交信の観点からデバッグが行われていることに注意してください。そのため、「Fr-MSG-TX」または送信メッセージは、DSP から接続先のファックス デバイスに送信されています。DSP が検出したことを示すメッセージ、または「fr-msg-det」メッセージは、DSP が接続先のファックス デバイスから受信したメッセージです。次の図は、debug fax relay t30 all コマンドが発行された際の DSP メッセージの方向性のフローを示しています。

    20227-faxrelay-tsguide4

    デバッグに示されたファックス トランザクションの失敗からは、相手側から「bad crc」メッセージがいくつか届いた後に続いて、Failure To Train（FTT）メッセージが届いていることがわかります。このデバッグから、問題にはトレーニング信号が含まれる可能性があると考えられます。相手側から返される bad crc エラーと Failure To Train（FTT）メッセージは、信号が壊れているか、または Cisco ファックス リレー プロトコルと互換性がないことを示しています。このデバッグは、Lexmark Optra ファックス機器でファックス リレーの問題が発生したときの出力です。LexmarkはV.34に対応しており、V.34レートで接続を試みます。V.34はCiscoファックスリレーではサポートされておらず、トレーニングエラーが発生します。詳細については、Cisco bug ID CSCdv89496（登録ユーザ専用）を参照してください。

    これらのデバッグの解読方法と、正常なデバッグおよび ECM モードでのファックス アナライザ トレースの例についての詳細は、『T.30 デバッグの動作例』ページで説明されています。

    Debug vtsp all

    この他にも、ファックス リレーの問題のトラブルシューティングに役立つ debug コマンドがあります。これらのデバッグは、T.30のデバッグほど読みや情報の提供が簡単ではありませんが、それでも役に立ちます。

    Voice Telephony Service Provider（VTSP）は、Cisco IOS のコール制御と DSP エンド ポイントの間のインターフェイスを定義するアーキテクチャです。DSP エンド ポイントは、アナログまたはデジタルのインターフェイスを通して、PBX やファックス、またはセントラル オフィスなどの標準の電話機器に接続されます。

    VoIP T.38またはファックスリレーでは、debug vtsp allによって、ルータからの有益なステート情報を取得できます。「トラブルシューティング」セクションで説明したように、ファックス コーデックが DSP にダウンロードされているかどうか、この debug コマンドを使用して判別できます（『音声テレフォニーのサービス プロバイダーによるデバッグ』ページを参照）。

    Debug vtsp vofr subframe 3

    VoFRおよびVoATMを使用するファックスで役立つもう1つのファックスリレーdebugコマンドには、debug vtsp vofr subframe 3があります。このコマンドは、Annex D のファックス リレー ペイロード タイプを持つ FRF11 フレームを出力します。このコマンドを使用すると、ファックス リレー コールが 1 つだけの場合でも大量の出力が発生し、16 進数をデコードする必要があります（16 進数のデコードには FRF11 の仕様書を参考にしてください）。

    追加のデバッグ コマンド

    1. T.38 機能の交換に関する問題をデバッグする場合は、debug cch323 h245 コマンドを使用します。

    2. アプリケーションと DSP の間で DSP メッセージ交換に関するデバッグを行う場合は、次の debug コマンドを使用します。

      • debug vtsp all

      • debug voip ccapi inout

      • debug hpi all（Cisco 5300、2600、3600、および TI c54x DSP を使用する他のすべての音声プラットフォームの場合）

      • debug nextport vsmgr detail（NextPort DSP プラットフォーム（Cisco 5400、5850）の場合）

    ファックス アナライザ

    しばしば、Cisco 音声ゲートウェイのデバッグ機能ではファックス リレーの問題を解決できないことがあります。ファックス リレーの動作中に発生している事象を調べるには、プロトコル アナライザやファックス アナライザなどのツールが使用されます。QualityLogic 社の Genoa ChannelProbe/FaxProbe や HP 社の Telegra などのファックス アナライザをファックス デバイスと Cisco ゲートウェイの間に配置して、発生している事象をキャプチャできます。Sniffer や Domino などのプロトコル アナライザは、ルータ間で交換されているファックス リレー パケットを確認する必要がある場合に役立ちます。

    複雑な問題を解決するためには、各ファックス機器ごとにファックスのトラフィックをキャプチャするアナライザと、ファックス リレー パケットをキャプチャするプロトコル アナライザを組み合せて使用することが必要な場合があります。ファックス コールを 1 回実行して問題が再現した後、接続デバイスからの情報を取得して分析します。次の図に、ネットワーク内にこのテスト機器を配置する場所を示します。

    20227-faxrelay-tsguide5

    ほとんどのファックス アナライザには、発生している事象を判断するのに役立つ、適切なヘルプ画面とドキュメントが備わっています。T.30 の仕様も、非常に役立ちます。プロトコルアナライザの場合、独自の符号化を使用している場合や、アナライザソフトウェアに必要な特定のデコードが含まれていない場合があるため、デコードが困難な場合があります。VoFRおよびVoATMを使用するファックスリレーの場合、CiscoゲートウェイはFRF11仕様の標準ベースのAnnex Dを使用します。プロトコル アナライザがフレームをデコードできない場合、フレームはこの仕様により手作業でデコードできます。VoIP によるファックスリレー では、Cisco の独自フォーマットがファックス リレー パケットとして使用されています。

    ファックスアナライザとプロトコルアナライザの情報があれば、ファックスリレーの問題を解決できます。この段階にまで到るファックス リレーの問題はほとんどありませんが、あった場合は、さらにサポートを得るためにエスカレーションと DE のリソースが必要になります。

    また、問題に関係のある他のすべての情報を提供してください。

    TAC ケースの作成

    このドキュメントを使用して問題の切り分けや解決ができない場合は、Cisco Technical Assistance Center（TAC）でサービスリクエストをオープンして、次の情報を提供してください。

    • ネットワーク トポロジの説明（PDF、Visio、または Microsoft PowerPoint 形式）

    • 使用しているファックス機器（ベンダーとモデルの情報も含む）

    • 問題の履歴

      新規のネットワーク、または今まで問題なく動作していた従来のネットワーク上で障害が発生したのか、などの情報が役に立ちます。ネットワークが従来のものである場合は、問題発生前にどんな変更を加えたのか。問題は断続的に発生するか。問題を再現できるか、および、再現できる場合は、問題を再現するために必要な手順についての情報が必要です。

    • 両方のファックス ゲートウェイと IP パス上にあるすべてのルータからの show tech コマンドの出力と、稼働している Cisco 以外のネットワーク機器に関する情報

    • 次のデバッグ フラグをイネーブルにしたコール トレースのペア

      • debug voip ccapi inout

      • debug vtsp all

      • debug isdn q931（ISDN または Q.Sig を使用する場合）

    • show voice call および show voice dsp 出力のペア

    • 発信元および終端のファックス機器にモニタモードで接続されているファックス アナライザ トレースのペア（ある場合）。

    • トラブルシューティングの結果とその時のデバッグ出力。弊社とのサポート契約がないお客様は、製品をご購入いただきました販売店経由にお問い合わせください。

    関連情報

    当初はhttps://www.cisco.com/c/en/us/support/docs/voice/fax-modem-over-ip/20227-faxrelay-tsguide.htmlに公開されました。

    元のMDFタグ：テクノロジー：音声：Fax / Modem over IP。
    文書IDは20227です 

    ドキュメントIDまたはURLが一致しない場合は、tz-writers@cisco.comにお問い合わせください。

    更新履歴

    改定 発行日 コメント
    1.0
    21-Feb-2002
    初版
    TAC Authored

    シスコ エンジニア提供

    • TACエンジニア

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ