ファックス リレー トラブルシューティング ガイド

ダウンロード オプション

  • PDF     (453.9 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (127.0 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (259.1 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2020 年 1 月 29 日
Document ID:20227

偏向のない言語

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

翻訳について

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

    概要

    このドキュメントは、Cisco FAX リレーの問題のトラブルシューティングと解決に関する基本的なガイドを提供することを目的としています。FAX および FAX リレーに関する複雑な技術的詳細については説明しませんが、ユーザは一般的な FAX リレーの問題のほとんどでトラブルシューティングを実行できるものと想定しています。FAX と Cisco FAX リレーの概要についても説明します。

    前提条件

    要件

    このドキュメントの読者は、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 テクノロジーについても説明しています。

    使用するコンポーネント

    このドキュメントの情報は、主に 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 経由のファックス コールを示しています。

    faxrelay_tsguide1.gif

    ページ送信速度、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 ポートに接続できます。

    faxrelay_tsguide2.gif

    設定に関する考慮事項

    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. Disable Fax Relay and Change Codec for Passthrough」で説明します。

    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 コマンド

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

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

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

    2. 基本接続のチェック

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

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

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

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

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

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

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

        注：設定されているダイヤルピアが一致するピアであることを確認します。

        次のコマンド出力では、発信 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...」の特定の一致したVoIPダイヤルピアの例です 発信ゲートウェイで発信し、終端ゲートウェイで着信します。

        発信元ゲートウェイ 終端ゲートウェイ 
        
!--- 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:1.1.1.1
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コールトレースの最初の行は、終端ゲートウェイの着信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および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 は適宜変わります）コマンドを何回か繰り返して、エラーの数が増えるかどうか確かめます。スリップの最も一般的な問題は、クロッキング エラーを引き起こす同期の問題です。

    パケット音声ネットワークでは、通常はルータで回線からのクロックが使用されていることを確認すれば十分です。そうではない場合は、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）を使用するプラットフォームではファックス コールが失敗するため、これは確認する重要なコマンドの 1 つです。

    fax interface-type vfcコマンドは、12.2より前のCisco IOSソフトウェアリリースでは必要ありませんでした。この問題は、音声ゲートウェイの1つを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 つめとして、コールごとの帯域幅使用量がネットワークの主な問題でない場合、ファックス リレー問題に対して潜在的なファックス パススルーの回避策があります。2 つめは、より重大であり、帯域幅の使用量が問題の場合、この問題はファックス リレー ソフトウェアの問題として切り分けられるので、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 以上の場合は、パケット損失について調査します。

    ネットワークでパケット損失が起こりやすいと思われる場合は、ファックス リレーの確実な動作を期待できません。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と表示される場合、FXRパッケージ設定がMGCPゲートウェイから欠落している可能性があります。この場合、MGCPゲートウェイに次のコマンドを追加します。 

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

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

    12. 解決の最終段階

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

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

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

      既知の注意事項

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

      CCOアカウントをお持ちの場合は、Cisco Bug Tracker Systemツール(Bug Search Tool)で既知の問題を検索できます。Bug Search Toolにアクセスするには、次のいずれかの作業を行います。

      表 1 既知の警告

      Bug ID 要約 説明
      CSCdu30250 VAD により、ファックス パススルー モードで重大なエラーが発生します。 Cisco 音声ゲートウェイがファックス パススルー モードに設定されている場合、ファックス コールに関連するすべての VoIP ダイヤルピアで Voice Activity Detection（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からWS-X6624-FXSゲートウェイへのファックスパススルーモード（のみ）で、Cisco CallManager 3-1-2c_spAロードA00203010026でファックス送信が失敗します。ゲートウェイとトールバイパスモードの両方で表示されます。 この障害は、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

      • リビジョン：0

      • 機能またはコンポーネント：VoFR

      • キーワード:ファクス

      不具合の 1 つに、「fax doesn't 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 のトランザクションを図で示します。

    faxrelay_tsguide3.gif

    これらのトランザクションの詳細についての説明はこのドキュメントの範囲外ですが、ファックス リレー中に見られる基本的なトランザクションの定義について次に説明します。ここではクイック リファレンスとしてトランザクションをアルファベット順に列挙しています。また、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 メッセージの方向性のフローを示しています。

    faxrelay_tsguide4.gif

    デバッグに示されたファックス トランザクションの失敗からは、相手側から「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 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 回実行して問題が再現した後、接続デバイスからの情報を取得して分析します。次の図に、ネットワーク内にこのテスト機器を配置する場所を示します。

    faxrelay_tsguide5.gif

    ほとんどのファックス アナライザには、発生している事象を判断するのに役立つ、適切なヘルプ画面とドキュメントが備わっています。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 出力のペア

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

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

    関連情報

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

    Feedbackフィードバック

    シスコに問い合わせ

    このドキュメントは次の製品に対応しています