コールトラッカー出力の理解

ダウンロード オプション

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

偏向のない言語

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

翻訳について

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

概要

このドキュメントでは、コールトラッカー出力について説明します。コールトラッカーは、コールの進捗と状態の詳細データを取得するために使用されるサブシステムです。ネットワーク アクセス サーバが設定要求を受信するか、チャネルを割り当ててから、コールが拒否、終了、または切断されるまでの時間が対象となります。

前提条件

要件

コール トラッカーおよび関連機能を設定する前に、ネットワーク アクセス サーバで次の作業を完了する必要があります。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

  • Cisco IOS®ソフトウェアリリース12.1(3)T以降

  • Cisco AS5300、AS5350、AS5400、AS5800 および AS5850 プラットフォーム。

注：Software Advisor(登録ユーザ専用)を使用して、使用するCisco IOSソフトウェアのバージョンとプラットフォームがこの機能をサポートしているかどうかを確認してください。Software Advisor ツールで、コール トラッカーと ISDN および AAA 強化という名前の機能を検索してください。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメントの表記法の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。

背景説明

コール トラッカーでキャプチャされたデータはコール トラッカー データベース テーブル内に保持され、SNMP、コマンドライン インターフェイス（CLI）、または Syslog を介してアクセスできます。すべてのアクティブなコールと設定状態のコールに関するセッション情報はアクティブ テーブルに保存され、切断されたコールのレコードは履歴テーブルに移動されます。コール トラッカーには、ISDN、Point-to-Point Protocol（PPP）、コンテンツ スイッチ モジュール（CSM）、モデム、Exec、または TCP-Clear などの関連サブシステムによって適用可能なコール イベントが通知されます。SNMP トラップは、エントリがアクティブ テーブルに作成される各コールの開始時と、エントリが履歴テーブルに作成される各コールの終了時に生成されます。コール レコード Syslog は、すべてのコール終了に関する詳細情報レコードを生成する構成を通じて、使用できます。この情報は、Syslog サーバに送信して、永続的に保管し将来の分析に使用することができます。

ここでは、いくつかの注意事項を示します。

  • MICA モデムから定期的に収集されるステータスおよび診断データは、アクティブ コールの新しいリンク統計情報を含めるように拡張されました。これらの統計情報には、試行した送受信レート、最大/最小送受信レート、ローカルおよびリモートで実行されたリトレインおよび速度シフト カウンタなどが含まれます。この接続データはユーザ定義された間隔でモデムからポーリングされ、コール トラッカーに渡されます。

  • TCP システムはコール トラッカーに追加の接続情報を提供するように強化されました。追加情報には次のものが含まれます。

    • 接続が確立される前に接続が試行されたホストの数と ID、または接続が確立されなかった場合は失敗した試行の合計。

    • アクティブ セッションが切断された理由、またはネットワーク アクセス サーバがタイムアウトする前にホストとの接続に失敗した理由。

    • ネットワーク アクセス サーバおよびホストの IP アドレスとポート番号で構成される、アクティブ セッションの送信元および宛先エンドポイント。

コール トラッカーの詳細については、Cisco AS5300 および Cisco AS5800 のコール トラッカーおよび ISDN/AAA の強化を参照してください。

コール トラッカーのメリット

この項では、コール トラッカーのメリットについて説明します。

  • コール トラッカーはコール アクティビティのより包括的でわかりやすいリアルタイム モニタリングを提供します。

  • コール トラッカーはアクティブ コール セッションと履歴コール セッションのデータをキャプチャし、外部アプリケーションが SNMP、CLI、または Syslog を介してそのデータにアクセスできるようにします。

  • コール トラッカーはコール管理の意思決定用に、ボリュームと使用率の統計情報を提供します。

  • コール トラッカーは、より詳細な出力を提供するため、modem call-record terse 機能を超えて改良されており、それに取って代わります。

    注：同様のSYSLOG出力を生成する可能性があるため、コールトラッカーとモデムコールレコードトレースを同時に有効にしないでください。同時に有効にすると、同じコールについて重複したエントリが生成される場合があります。

コール トラッカーの構成

コマンドの要約

コール トラッカーを設定するには、（リストされている順序で）次のコマンドを使用します。

  1. enable

  2. configure terminal

  3. calltracker enable

  4. calltracker call-record

  5. calltracker history max-size

  6. calltracker history retain-mins

  7. snmp-server packetsize byte-count

  8. snmp-server queue-length

  9. snmp-server enable traps calltracker

  10. snmp-server host host community-string calltracker

  11. calltracker timestamp msec （オプション）

  12. modem link-info poll time or spe link-info poll modem （オプション）

  13. exit

コマンドの詳細

  コマンド 目的
ステップ 1： enable 例： Router> enable 特権 EXEC モード、またはシステム管理者によって設定されたその他のセキュリティ レベルを開始します。パスワードを入力します（要求された場合）。
ステップ 2： configure terminal 例： Router# configure terminal グローバル コンフィギュレーション モードを開始します
ステップ 3： calltracker enable 例： Router(config)# calltracker enable NAS でコール トラッカーを有効にします。
ステップ 4： calltracker call-record {terse | verbose} [quiet] 例： Router(config)# calltracker call-record verbose quiet 提供された情報は、コール トラッカーのコール履歴テーブルから SNMP および Syslog によって収集できます。terse オプションは簡潔なコール レコード セットを生成します。これには、主にコール管理に使用される、コール トラッカー内に保存されたデータのサブセットが含まれます。verbose オプションは、詳細なコール レコード セットを生成します。これには、主にコールのデバッグに使用される、コール トラッカー内に保存されているすべてのデータが含まれます。quiet オプションを使用すると、コール レコードは設定された Syslog サーバのみに送信され、コンソールには送信されません。
ステップ 5： calltracker history max-size number 例： Router(config)# calltracker history max-size 50 履歴バッファ（コール トラッカー履歴テーブルに保存されるコール エントリの最大数）を設定するには、calltracker history max-size number コマンドを使用します。 number は、コール トラッカー履歴テーブルに保存されるコール エントリの最大数です。有効な範囲は、特定のプラットフォームでサポートされる最大 DS0 の 0 倍から 10 倍です。値 0 を指定すると履歴は保存されません。レポート タスクが優先順位の高いプロセスではなく、使用可能な CPU を待機する必要があるため、コール トラッカーでは、コールが切断されてからレポートするまでに最長で 1 分間かかることがあります。そのため、履歴バッファは、レポートされたデータを保存するために十分なサイズに設定する必要があります。バッファ サイズを設定する場合は、コールの通話時間とタイプ（ISDN はモデムよりも短い）を考慮し、1 分間で受信できるコールの最大数を決定します。また、設定エラーまたはハードウェア障害が発生すると、コール レートが比較的高くなる場合があります。したがって、プラットフォームのポート数の 4 倍を使用することをお勧めします。詳細については、Cisco AS5300 および Cisco AS5800 のコール トラッカーおよび ISDN/AAA の強化を参照してください。
手順 6： calltracker history retain-mins minutes 例： Router(config)# calltracker history retain-mins 5000 コール トラッカー履歴テーブルにコールを保存しておく分数を設定します。 minutes はコールを保存する時間の長さです。有効な範囲は、0 ～ 26,000 分です。値 0 を指定するとコールは保存されません。
手順 7： snmp-server packetsize byte-count 例： Router(config)# snmp-server packetsize 1024 SNMP サーバが要求を受信するか、または応答を生成するときに許可される SNMP パケットの最大サイズに対する制御を確立します。 byte-count は、484 ～ 8192 の整数です。デフォルトは 1500 です。
ステップ 8： snmp-server queue-length length 例： Router(config)# snmp-server queue-length 50 各トラップ ホストのメッセージ キューの長さを定義します。トラップ メッセージが正常に送信される場合、Cisco IOS ソフトウェアはキューが空になるまで送信し続けます。ただし、キューは、4 トラップ メッセージ/秒のレートより早く空にしないでください。デバイスの起動中に、デバイスのトラップ キューのオーバーフローが原因で、一部のトラップがドロップされる場合があります。トラップがドロップされていると思われる場合は、トラップのキューのサイズを（たとえば、100 に）増やし、その後、起動中にトラップを送信できるかどうか判別します。length は、キューを空にする必要が生じる前に、保留できるトラップ イベントの数を指定する整数です。デフォルトは 10 です。
ステップ 9： snmp-server enable traps calltracker 例： Router(config)# snmp-server enable traps SNMP 通知は、トラップまたはインフォーム要求として送信できます。このコマンドは、トラップとインフォーム要求の両方を有効にします。このコマンドは、コール トラッカー CallSetup および CallTerminate 通知を制御（有効化または無効化）します。CallSetup 通知は、各コールの開始時に、エントリがアクティブ テーブル（cctActiveTable）に作成されたときに生成されます。 CallTerminate 通知は、各コールの終了時に、エントリが履歴テーブル（cctHistoryTable）に作成されたときに生成されます。
ステップ 10： snmp-server host host community-string calltracker 例： Router(config)# snmp-server host host community string calltracker SNMP 通知の受信者を指定します。SNMP 通知は、トラップまたはインフォーム要求として送信できます。受信側はトラップを受信しても確認応答を送信しないので、トラップの信頼性は高くありません。送信側は、トラップが受信されたかどうかを判断できません。しかし、SNMP エンティティはインフォーム要求を受信すると、SNMP 応答プロトコル データ ユニット（PDU）でメッセージに確認応答します。 送信側が応答をまったく受け取っていなければ、インフォーム要求を再送信できます。このため、インフォームは、目的の宛先に到達できる可能性が高くなります。トラップと比較すると、インフォームはエージェントおよびネットワークのリソースをより多く消費します。送信と同時に廃棄されるトラップと異なり、インフォーム要求は応答を受信するまで、または要求がタイムアウトになるまで、メモリ内に保持されます。また、トラップは一度だけ送信されますが、インフォームは何度も再試行できます。再送信の回数が増えるとトラフィックが増加し、ネットワークのオーバーヘッドが高くなる原因になります。snmp-server host コマンドを入力しなければ、通知はまったく送信されません。SNMP 通知を送信するようにルータを設定するには、snmp-server host コマンドを少なくとも 1 回入力する必要があります。キーワードを付けずにコマンドを入力すると、すべてのトラップ タイプがホストで有効になります。複数のホストを有効にするには、各ホストに対して個別に snmp-server host コマンドを実行する必要があります。ホストごとに、コマンドで、複数の通知タイプを指定することができます。同じホストや通知タイプ（トラップまたはインフォーム）に複数の snmp-server host コマンドを発行すると、コマンドを発行するたびに前のコマンドが上書きされます。最後の snmp-server host コマンドだけが有効です。たとえば、ホストに対してsnmp-server host informコマンドを入力し、同じホストに対して別のsnmp-server host informコマンドを入力した場合は、2番目のコマンドが最初のコマンドに置き換わります。
ステップ 11 calltracker timestamp msec （オプション）例：Router(config)# calltracker timestamp msec アクセス サーバのコール レコード（CDR）にコール セットアップ時間をミリ秒値で表示します。このコマンドを実行しないと、コール セットアップ時間は秒単位で表示されます。

注：このコマンドは、Cisco IOSリリース12.3(4)および12.3(4)Tでのみ使用できます。
ステップ 12 modem link-info poll time seconds （オプション）または spe link-info poll modem seconds （オプション）例：Router(config)# modem link-info poll time 320 コール トラッカーのモデム詳細レコードを有効にします。オプションで、modem link-info poll time seconds コマンドまたは spe link-info poll modem seconds コマンドのいずれかを使用できます。これらのコマンドは、アクティブ コールのリンク統計をモデムから取得するポーリング間隔を設定します。ポーリング間隔の推奨値は 320 秒です。MICA テクノロジー モデムからのコール トラッカーへのリアルタイム コール統計情報を有効にするには、modem link-info poll time コマンドを使用する必要があります。

注：modem link-info poll timeコマンドは、MICAモデムコールごとに約500バイトの大量のメモリを消費します。このコマンドは、収集される特定のデータが必要な場合にだけ使用してください。
ステップ 13 exit 例： Router(config)# exit 現在のモードを終了します。

コール トラッカーの出力

コール トラッカーの出力は複数のレコードに分割されています。この表は、コール トラッカー出力レコードを一覧し、説明しています。

レコード名 説明
CALL_RECORD すべてのコール カテゴリ間で共有される汎用データ。有効なパラメータのリストについては、CALL_RECORD パラメータを参照してください。
MODEM_CALL_RECORD 全体的なモデム コール情報。有効なパラメータのリストについては、MODEM_CALL_RECORD パラメータを参照してください。
MODEM_LINE_CALL_REC モデムのトランスポート層および物理層の情報（包括的なデバッグ用）。 有効なパラメータのリストについては、MODEM_LINE_CALL_REC パラメータを参照してください。
MODEM_INFO_CALL_REC モデム ステータス情報（包括的なデバッグ用）。 有効なパラメータのリストについては、MODEM_INFO_CALL_REC パラメータを参照してください。
MODEM_NEG_CALL_REC クライアントとホストのネゴシエーション情報（包括的なデバッグ用）。 有効なパラメータのリストについては、MODEM_NEG_CALL_REC パラメータを参照してください。

注：同じコールを参照するレコードは、パラメータct_hndlで同じ一意の値で始まります。

CALL_RECORD パラメータ

次の表は CALL_RECORD パラメータを一覧し、説明しています。

パラメータ 説明
ct_hndl コール トラッカー ハンドル。アクティブ コールを処理するためにコール トラッカーが使用する一意の番号。呼び出しには、1 ～ 4,294,967,296のID番号が割り当てられます。これらのIDは1で始まり、1ずつ増加します。4,294,967,295呼び出しの後、IDは折り重れ、4,24,29667,2 96番目のコールは、1から始まる次に小さい使用可能な番号を受信します。コール履歴、syslog、およびSNMPレコードは、異なるコールに対して同じID番号を持つことができます。これは、番号がアクティブ コールに対してのみ一意であるためです。0 は有効な値ではありません。
サービス サービス タイプ。最後に認識されていたコールのサービス タイプをレポートします。
  • none – コールに関連付けられたサービスはありません
  • other – サービスはアクティブだが、次のいずれでもありません。
  • slip – シリアル回線 IP
  • ppp – PPP
  • mp – マルチリンク PPP（RFC 1990）
  • tcpClear – TCP 経由のバイト ストリーム
  • telnet – TELNET
  • exec – ターミナル サーバ
  • l2f：レイヤ2転送プロトコルを使用する仮想プライベートデータネットワークサービス(VPDN)
  • l2tp：レイヤ2トンネリングプロトコルを使用する仮想プライベートデータネットワークサービス(VPDN)
Origin コールが作成された方法を示します。
  • originate – ダイヤルアウト。コールはローカルで開始され、システムがセットアップ要求を送信します。
  • answer – ダイヤルイン。コールはリモートで開始され、システムはセットアップ要求を受信します。
Call Category 有効なコール カテゴリまたはタイプを表します。
  • none – コールに関連付けられているコール カテゴリはありません
  • other – 次のいずれでもありません。
  • modem – モデム コール
  • isdn-sync – ISDN 同期デジタル コール。現在 syncData にマッピングされている
  • v110 - V110コール
  • v120 - V120コール
  • cas-digital：個別線信号方式(CAS)56kデータコール
  • mgcpData – MGCP データ コール。現在 syncData にマッピングされている
  • syncData – コール制御用の同期デジタル データ コール
  • lapb-ta – LAPB または LAPB-TA コール
DS0 slot/cntr/chan スロット/ポート/DS0 のエントリ。コールを含む DS0 リンク。これは単一の物理ポート内の複数の DS0 から成る大規模なグループに含まれる DS0 である場合があります。
called 着信側 ID。このコールの発信先電話番号。システムによって応答されるコールの場合、これは着信番号 ID（DNIS）に相当します。 システムにより発信されたコールの場合、これは接続先番号です。使用できない場合、これは長さゼロの文字列です。
calling 発信者 ID。このコールの発信元電話番号。システムによって応答されるコールの場合、これは発信者 ID（CLID）に相当します。 システムにより発信されたコールの場合、これはデバイスに関連付けられた番号です。インターワーキング コールで、ダイヤル プランに関連付けられた発信コールのトランスレーション ルールがある場合、これは変換された発信者番号です。使用できない場合、これは長さゼロの文字列です。
resource slot/port リソースのスロット/ポート。コールに割り当てられた処理リソースの ID。
userid ユーザ名 ID。ユーザ ログイン ID または使用できない場合は長さゼロの文字列。長さが 0 以外の文字列が含まれており、cctHistoryUserValidationTime が 0 の場合、ユーザは検証に失敗します
ip IP アドレス。このコールに割り当てられた IP アドレスまたは適用/使用できない場合は 0.0.0.0。
mask IP サブネット マスク。このコールに割り当てられた IP サブネット マスクまたは適用/使用できない場合は 0.0.0.0。
account id アカウンティング セッション ID。AAA によってこのコールに割り当てられたアカウンティング セッション ID。セッション ID は AAA によって、Acct-Session-Id 属性として RADIUS に送信されるか、または task_id として TACACS+ に送信されます。アカウンティング セッション ID が割り当てられていない場合、値はヌル ストリングです。
setup 設定時間。コールが最初にシステムに認識された時点のタイムスタンプ。
conn 接続時間。コールが接続されるまでに要した時間（秒単位）。
phys 物理層レディ。物理層が定常状態に達し、コールを上位プロトコル層で開始する準備が整うまでに要した時間（秒単位）。モデム コールの場合、コールの物理層は、データ レート、変調およびエラー訂正プロトコルが発信側モデムと応答側モデムの間でネゴシエートされると定常状態に達します。また、V.110 や V.120 などのアダプティブ レート テクノロジーを使用するデジタルコールにも適用されます。
srvc サービス時間。サービス タイプを識別するために要した時間。
auth 認証時間。このコールに関連付けられたユーザ ID を検証するために要した時間（秒単位）。
init rx/tx b-rate 初期受信/送信ビット レート。このコールの初期送受信データ レート。コールが ISDN 同期などの同期デジタル コールの場合、この値は B チャネルのデータ レートです。コールが非同期の場合は、ISDN などの同期伝送メディアを使用していても、値は MICA または Nextport モデムによってネゴシエートされた速度（ビット/秒）になります。コール中にデータ レートが変わっても、この値は変更されません。初期データ レートが判別されるまで、この値はゼロです。
rx/tx chars 送信/受信バイト。コールで送信されたバイト数。すべての raw バイトが計数されます。この値にはプロトコル ヘッダーが含まれます。プロトコル ヘッダーは存在する場合もあれば、存在しない場合もあります。プロトコル ヘッダーが存在するかどうかは、サービスの値によって異なります。
時間 接続時間。コールが接続されている時間（秒単位）。これは、初期設定要求からシステムがコール終了を開始、検出、またはコール終了の通知を受信するまでの通話時間（秒単位）です。
disc subsys 切断サブシステム。コール終了を開始、検出、またはコール終了の通知を受信する IOS サブシステム。サブシステム タイプ：
  • admin
  • csm
  • isdn mica
  • none
  • ppp
  • rpm（リソース プール管理）
  • vpn（バーチャル プライベート ネットワーク）
  • vtsp（音声テレフォニー）

    注：この情報には、Cisco IOSソフトウェアに関する知識が平均的なユーザよりも多く必要ですが、接続の問題をトラブルシューティングする際にはシスコテクニカルサポートの担当者が役立ちます。

disc code 切断原因コード。このコールが終了された理由を示すコード。詳細については、次のドキュメントを参照してください。
disc text 切断の説明。提供された切断の理由を説明するテキスト。テキストが使用できない場合、これは長さがゼロの文字列となることがあります。詳細については、次のドキュメントを参照してください。

例 

*Nov 16 18:30:26.097: %CALLTRKR-3-CALL_RECORD: 
   ct_hndl=5, service=PPP, origin=Answer, category=Modem, 
   DS0 slot/cntr/chan=0/0/22, called=71071, calling=6669999, 
   resource slot/port=1/0, userid=maverick5200, ip=192.9.1.2, 
   mask=255.255.255.0, account id=5, setup=10/16/1999 18:29:20, 
   conn=0.10, phys=17.12, srvc=23.16, auth=23.16, init-rx/tx 
   b-rate=31200/33600, rx/tx chars=246/161, time=53.50, disc 
   subsys=ModemDrvr, disc code=0xA220, disc text= Rx (line to host) 
   data flushing - not OK/EC condition - locally detected/received 
   DISC frame -- normal LAPM termination

MODEM_CALL_RECORD パラメータ

次の表は MODEM_CALL_RECORD パラメータを一覧し、説明しています。

パラメータ 説明
ct_hndl コール トラッカー ハンドル。アクティブ コールを処理するためにコール トラッカーが使用する一意の番号。呼び出しには、1 ～ 4,294,967,296のID番号が割り当てられます。これらのIDは1で始まり、1ずつ増加します。4,294,967,295呼び出しの後、IDは折り重れ、4,24,29667,2 96番目のコールは、1から始まる次に小さい使用可能な番号を受信します。コール履歴、syslog、およびSNMPレコードは、異なるコールに対して同じID番号を持つことができます。これは、番号がアクティブ コールに対してのみ一意であるためです。0 は有効な値ではありません。
prot:last エラー訂正プロトコル：最終。最後に使用されたことが認識されたエラー訂正（EC）プロトコルをレポートします。EC プロトコル：
  • normal（EC は存在しない）
  • direct
  • mnp
  • lapmV42
  • syncMode
  • asyncMode（EC は存在せず、normal と同じ）
  • ara1（ARA 1.0）
  • ara2（ARA 2.0）
  • other（特定された上記以外の EC プロトコル）
prot:attempt エラー訂正プロトコル：試行。最初に試行されたエラー訂正（EC）プロトコルをレポートします。有効な EC プロトコルについては、prot:last を参照してください。
comp:last 圧縮プロトコル：最終。コールが終了する前に、最後に使用されていた圧縮プロトコルをレポートします。圧縮プロトコルは次のとおりです。
  • none（データ圧縮は存在しない）
  • v42bisTx（送信方向の V.42bis のみ）
  • v42bisRx（受信方向の V.42bis のみ）
  • v42bisBoth（双方向の V.42bis）mnp5
  • v44Tx（送信方向の V.44 のみ）
  • v44Rx（受信方向の V.44 のみ）
  • v44Both（双方向の V.44）
comp:supp 圧縮プロトコル：サポート。サポート可能な圧縮プロトコル。有効な圧縮プロトコルについては、comp:last を参照してください。
std:last 標準：最終。これは、コールが終了する前に、最後に使用されていた変調の標準です。変調の標準は次のとおりです。
  • other（特定された下記以外の変調）
  • bell103a
  • bell212a
  • v21
  • v22
  • v22bis
  • v32
  • v32bis
  • vfc
  • v34
  • v17
  • v29
  • v33
  • k56flex
  • v23
  • v32terbo
  • v34plus
  • v90
  • v27ter
  • v110
std:attempt 標準：試行。クライアント側のモデムで試行された変調の標準。有効な変調の標準については、std:last を参照してください。
std:init 標準：初期。クライアント側のモデムで最初に試行された変調の標準。有効な変調の標準については、std:last を参照してください。
std:snr 標準：信号対雑音比。必要とされる信号対雑音比の基準。この値は、0 ~ 70 dB の範囲で、1 dB ずつ変更できます。28.8 Kbps の接続では、約 37 dB の SNR が要求される点に注意してください。これより低いと、接続の品質が低下します。33.6 Kbps の接続では、38 ～ 39 dB の SNR が要求される点に注意してください。また、「クリーン」な回線は SNR が約 41 dB である点に注意してください。
std:sq 標準：信号品質。0 が最低で、3 が定常状態の特定のビット レートを得るための回線品質の基準。1 または 2 が存在する場合は、モデムをより低いレートに切り替える必要があります。同様に、Sq 値が 4 ~ 7 の場合、モデムの速度はより高いレートに切り替わります。Sq 値が高く（たとえば 7）、ビット レートが低い場合は、リモート エンドのレシーバで問題が生じている可能性があります。
rx/tx:chars 受信/送信：文字。コールで送信されたバイト数。すべての raw バイトが計数されます。この値にはプロトコル ヘッダーが含まれます。プロトコル ヘッダーは存在する場合もあれば、存在しない場合もあります。プロトコル ヘッダーが存在するかどうかは、サービスの値によって異なります。
ec:rx/tx 受信/送信：エラー訂正フレーム。送受信された EC フレームの数。
ec:rx bad エラー訂正：受信した不良フレーム。エラーが発生した EC フレームの数。
rx/tx b-rate:last 受信/送信ビット レート：最終。コールの終了時の最後の受信/送信ビット レート。
rx/tx b-rate:low 受信/送信ビット レート：低。コールの通話期間中に発生した最低の受信/送信ビット レート。
rx/tx b-rate:high 受信/送信ビット レート：高。コールの通話期間中に発生した最高の受信/送信ビット レート。
rx/tx b-rate:desired-client 受信/送信ビット レート：クライアントによる要求。クライアントが維持することを望む送受信ビット レート。ホストは適応するためにトレインアップ/ダウンしない場合があるため、ホストがレポートするビット レートが常にこの値であるとは限りません。
rx/tx b-rate:desired-host 受信/送信ビット レート：ホストによる要求。ホストが維持することを望む、ホストによって要求された送受信ビット レート。
retr:local リトレイン：ローカル。ローカルで開始されたリトレインの数。
retr:remote リトレイン：リモート。リモート モデムによって開始されたリトレインの数。
retr:fail リトレイン：失敗。失敗したリトレインの数。
speedshift:local up/down 速度切り替え：ローカル アップ/ダウン。ローカル モデムによって開始された速度のアップ/ダウン切り替えの回数。
speedshift:remote up/down 速度切り替え：リモート アップ/ダウン。リモート モデムによって開始された速度のアップ/ダウン切り替えの回数。
speedshift:fail 速度切り替え：失敗。失敗した速度切り替えの回数。
v90:stat V.90 ステータス。コールが終了する前の V90 のステータス。有効なステータス値は次のとおりです。
  • no attempt
  • 成功
  • failure
v90:client V.90：クライアント。V.90 クライアント モデムによって使用されるチップセット。
  • 該当なし
  • [不明（Unknown）]
  • Rockwell
  • USR
  • Lucent
  • PCTel
v90:fail V.90 障害。V.90 の障害。V.90 の障害は次のとおりです。
  • none
  • clientNonPCM
  • clientFallback
  • serverV90Disabled
time(sec) 時間（秒）。コールの持続期間。この値は、トレインアップまたは認証の結果に関係なく、常に返されます。
disc reason 切断理由。コールを切断する MICA または NextPort モデムによって提供される ASCII コード。詳細については、次のドキュメントを参照してください。

例 

*Nov 16 18:30:26.097: %CALLTRKR-3-MODEM_CALL_REC: 
   ct_hndl=5, prot: last=LAP-M, attempt=LAP-M, comp: last=V.42bis-Both, 
   supp= V.42bis-RX V.42bis-TX, std: last=V.34+, attempt=V.34+, init=V.34+, 
   snr=38, sq=3, rx/tx: chars=246/161, ec: rx/tx=22/12, rx bad=46, 
   rx/tx b-rate: last=33600/33600, low=31200/33600, high=33600/33600, 
   desired-client=33600/33600, desired-host=33600/33600, retr: local=0, 
   remote=0, fail=0, speedshift: local up/down=1/0, remote up/down=0/0, 
   fail=0, v90: stat=No Attempt, client=(n/a), fail=None, time(sec)=52, 
   disc reason=0xA220MODEM_LINE_CALL_REC Parameters

MODEM_LINE_CALL_REC パラメータ

次の表は MODEM_LINE_CALL_REC パラメータを一覧し、説明しています。

パラメータ 説明
ct_hndl コール トラッカー ハンドル。アクティブ コールを処理するためにコール トラッカーが使用する一意の番号。呼び出しには、1 ～ 4,294,967,296のID番号が割り当てられます。これらのIDは1で始まり、1ずつ増加します。4,294,967,295呼び出しの後、IDは折り重れ、4,24,29667,2 96番目のコールは、1から始まる次に小さい使用可能な番号を受信します。コール履歴、syslog、およびSNMPレコードは、異なるコールに対して同じID番号を持つことができます。これは、番号がアクティブ コールに対してのみ一意であるためです。0 は有効な値ではありません。
rx/tx levl 受信/送信レベル。受信/送信信号のパワー。0 ～ -128 dBm の範囲で dBm 単位で調整します。通常、米国では約 -22 dBm、ヨーロッパでは -12 dBm です。適切な範囲は -12 ~ -24 dBm です。詳細については、以下を参照してください。モデムの送受信レベルの理解を参照してください。
phase-jit:freq フェーズジッター：周波数。2 つの信号ポイント間のピーク ツー ピーク差分（ヘルツ単位）。キャンセルされないフェーズジッターは、ベースバンド直交振幅変調（QAM）コンステレーションの「揺動」のように見えます。ポイントは、外部ポイント上により長い弧を備えた円弧のように見えます。
phase-jit:levl フェーズジッター：レベル。測定されたフェーズジッターのレベル量で、「揺動」の大きさ（度単位）を示します。オシロスコープでは、コンステレーション ポイントは三日月のように見えます。値の範囲は最大 15 度までです。典型的な値は 0 です（通常、フェーズジッターは存在しません）。
far-end echo-levl 遠端エコーレベル。長距離接続では、2 線対 4 線および 4 線対 2 線のハイブリッド回路におけるインピーダンスの不一致によってエコーが生成されます。遠端エコー レベル（送信アナログ信号で、リモートモデムのアナログ フロントエンドのバウンスした部分）は 0 ~ -90 dBm の範囲となる場合があります。
freq offst 周波数オフセット。予想 RX キャリア周波数と実際の RX キャリア周波数の差（ヘルツ単位）。
phase-roll フェーズ ロール。フェーズ ロールは戻ってくるエコー信号に影響します。特定のコンステレーション パターンがモデムから送信され、セントラル オフィスに到達します。この信号/コンステレーション パターンのエコーされた形式が戻されます。ただし、コンステレーションの形状が、0 ~ 359 度回転している場合があります。この回転がフェーズ ロールと呼ばれています。
round-trip ラウンド トリップ遅延。リンクのラウンド トリップ伝搬遅延の合計（ミリ秒単位）。 これは、適切なエコー キャンセレーションを実現するために重要です。ネットワーク上での遅延の変動量。
d-pad デジタルパッド。デジタル パディング値。
d-pad comp デジタルパッド圧縮。これは、圧縮を表す整数です。
  • 0 = なし
  • 1 = V.42bis TX
  • 2 = V.42bis RX
  • 3 = V.42bis 双方向
  • 4 = MNP5
  • 5 = MH（FAX）
  • 6 = MR（FAX）
  • 7 = MMR（FAX）
  • 8 = V.44 TX
  • 9 = V.44 RX
  • 10 = V.44 双方向
  • 0xFF (-1) = データ圧縮は未ネゴシエート
rbs ロブド ビット シグナリング。モデムによって監視された実際の RBS パターン。戻り値の 6 桁の最下位ビット（LSB）は、1 つの 1 が 1 ロブド ビットの PCM サンプルを表す定期的な RBS パターンを示しています。
const コンステレーション。これはコンステレーションのポイント数です。
  • 0xFF = 無効
  • 1 = 4 ポイント
  • 2 = 16 ポイント
rx/tx:sym-rate 受信/送信：シンボルレート。TX は回線にサンプルを送信するために使用されるシンボル レートです。RX は回線からサンプルを受信するために使用されるシンボル レートです。レートは相互に同期されます。
rx/tx:carr-freq 受信/送信：キャリア周波数。TX の場合は、ローカル DCE が使用するキャリア周波数。RX の場合は、リモート DCE が使用するキャリア周波数。

例 

*Nov 16 18:30:26.101: %CALLTRKR-3-MODEM_LINE_CALL_REC: 
   ct_hndl=5, rx/tx levl=-17/-16, phase-jit: freq=0, levl=0, 
   far-end echo-levl=-71, freq offst=0, phase-roll=-98, 
   round-trip=1, d-pad=None, d-pad comp=0, rbs=0, const=16, 
   rx/tx: sym-rate=3429/3429, carr-freq=1959/1959, trel-code=0/0, 
   preemph-index=6/0, rx/tx: const-shape=Off/On, nonlin-encode=Off/On, 
   precode=Off/On, xmit levl-reduct=2/3, 
   shape=0x1920212120202120202020202020202020202020201F1D191100

MODEM_INFO_CALL_REC パラメータ

次の表は MODEM_INFO_CALL_REC パラメータを一覧し、説明しています。

パラメータ 説明
ct_hndl コール トラッカー ハンドル。アクティブ コールを処理するためにコール トラッカーが使用する一意の番号。呼び出しには、1 ～ 4,294,967,296のID番号が割り当てられます。これらのIDは1で始まり、1ずつ増加します。4,294,967,295呼び出しの後、IDは折り重れ、4,24,29667,2 96番目のコールは、1から始まる次に小さい使用可能な番号を受信します。コール履歴、syslog、およびSNMPレコードは、異なるコールに対して同じID番号を持つことができます。これは、番号がアクティブ コールに対してのみ一意であるためです。0 は有効な値ではありません。
general info 一般情報。一般的なポートウェア情報。
rx/tx link-layer 受信/送信リンク層。受信または送信されたリンク層。
NAKs NAK。確認応答されていない送受信済みの LCP メッセージの合計。
rx/tx ppp-slip 受信/送信 PPP-SLIP。受信または送信された PPP および Slip フレームの数。
bad ppp-slip 不良 PPP-SLIP。受信または送信された不良 PPP および Slip フレームの数。
proj max rx b-rate:client 予想最大受信ビット レート：クライアント。クライアントの予想される最大受信ビット レート。
rproj max rx b-rate:host 予想最大受信ビット レート：ホスト。ホストの予想される最大受信ビット レート。
rx/tx:max neg I frame 受信/送信：最大ネゴシエート I フレーム。フレームの送受信最大ネゴシエート値。
rx/tx:neg window 受信/送信：ネゴシエート ウィンドウ。送受信ネゴシエーション ウィンドウ。
T401 timeouts T401 タイムアウト。V.42 EC が有効なクライアントへの接続を確立し、CSM からデータを渡します。データを渡す前と、転送が成功した後に再度、統計をクエリします。統計が、増分されることはありません。
tx window closures 送信ウィンドウ クローズ。クライアントへの接続を確立し、CSM からデータを渡します。ウィンドウが閉じており、クライアント モデムから ACK/NAK を受信していない場合にのみ、統計が増分されます。予想結果は、0 を示します。
rx overruns 受信したオーバーラン。受信したオーバーランの合計。
retrans frames リトレイン フレーム。開始されたリトレイン フレームの合計。
v110:rx good V.110：受信した正常フレーム。受信した正常な v110 フレームの数。
v110:rx bad V.110：受信した不良フレーム。受信した不良の v110 フレームの数。
v110:tx V.110：送信。送信された v110 フレームの数。
v110:sync lost v110:同期はずれ。v110 の同期が失われた回数。
ss7/cot No.7 共通線信号方式（SS7）および連続性テスト（COT）統計。
v42bis size:dict V.42bis サイズ：ディクショナリ。v42bis ディクショナリ サイズを提供します。
test err テスト エラー。発生したセルフ テスト エラー。
reset リセット。DSP が値をリセットします。
v0 synch-loss V.0同期損失クライアントとの接続を確立し、クエリが0であることを確認します。このカウンタは、再確立をトリガーする受信信号でV0同期が失われた場合にのみ増加する必要があります。
メール損失：host メール損失：ホスト。失われたホストのメールの数。
sp SP。失われた sp のメールの数。
diag 診断。ポートウェア診断の値。

例 

*Nov 16 18:30:26.101: %CALLTRKR-3-MODEM_INFO_CALL_REC: 
   ct_hndl=5, general info=0x0, rx/tx link-layer=264/182, NAKs=0/0, 
   rx/tx ppp-slip=5/7, bad ppp-slip=0, proj max rx b-rate: client=19200, 
   host=24000, rx/tx: max neg I frame=128/128, neg window=15/15, 
   T401 timeouts=1, tx window closures=0, rx overruns=0, retrans frames=0, 
   v110: rx good=0, rx bad=0, tx=0, sync-lost=0, ss7/cot=0x00, 
   v42bis size: dict=1024, test err=0, reset=0, v0 synch-loss=0, mail lost: 
   host=0, sp=0, diag=0x00000000000000000000000000000000

MODEM_NEG_CALL_REC パラメータ

次の表は MODEM_NEG_CALL_REC パラメータを一覧し、説明しています。

パラメータ 説明
ct_hndl コール トラッカー ハンドル。アクティブ コールを処理するためにコール トラッカーが使用する一意の番号。呼び出しには、1 ～ 4,294,967,296のID番号が割り当てられます。これらのIDは1で始まり、1ずつ増加します。4,294,967,295呼び出しの後、IDは折り重れ、4,24,29667,2 96番目のコールは、1から始まる次に小さい使用可能な番号を受信します。コール履歴、syslog、およびSNMPレコードは、異なるコールに対して同じID番号を持つことができます。これは、番号がアクティブ コールに対してのみ一意であるためです。0 は有効な値ではありません。
v8bis cap V.8bis 機能。V.8bis が 16 進数で表されている間に受信した機能リスト。これらのビットに関する詳細については、ITU-T V.8bis を参照してください。
v8bis mod_sl V.8 モード選択。V.8bis が 16 進数で表されている間に選択されるモード。これらのビットに関する詳細については、ITU-T V.8bis を参照してください。
v8 jnt-menu V.8 ジョイントメニュー。V.8bis が 16 進数で表されている間に交換されるジョイント メニュー。これらのビットに関する詳細については、ITU-T V.8 を参照してください。
v8 call-menu V.8 コールメニュー。V.8bis が 16 進数で表されている間に交換されるコール メニュー。これらのビットに関する詳細については、ITU-T V.8 を参照してください。
v90 train V.90 トレイン。V.90 トレインの 16 進数表記。
v90 sgn-ptrn V.90 信号パターン。V.90 信号パターン。
state tsrnsn 状態遷移。状態遷移の値。
phase2 フェーズ 2。フェーズ 2 では、L1 を除くすべての信号が公称の送信電力レベルで送信されます。リカバリ メカニズムが後のフェーズからフェーズ 2 へモデムを戻した場合、送信レベルも以前にネゴシエートされた送信電力レベルから公称の送信電力レベルに戻ります。

例 

*Nov 16 18:30:26.101: %CALLTRKR-3-MODEM_NEG_CALL_REC: 
   ct_hndl=5, v8bis cap=0x00000000000000000000000000000000000000000000, 
   v8bis mod-sl=0x00000000000000000000000000000000000000000000, 
   v8 jnt-menu=0x01E0C14513942A000000000000000000000000000000, 
   v8 call-menu=0x01C14513942A00000000000000000000000000000000, 
   v90 train=0x00000000, v90 sgn-ptrn=0x00000000, state 
   ·trnsn=0x000102030410204042430451FF00000000000000000000000000000000000000, 
   phase2=0x010000F4EF221FF37E0001E4EFA21FF2E30001A4EF980101B7CF98003C000000
   0034EF40000502160AE0301FFFFE1C07A707A70D650D6500Related

関連する SNMP MIB

SNMP MIB

次の表は、関連する SNMP MIB を一覧し、説明しています。

[名前(Name)] 説明
RFC1406-MIB リンク状態遷移。
CISCO-CALL-TRACKER-MIB コール トラッカー情報。
CISCO-MODEM-MGMT-MIB モデム管理情報。
CISCO-POP-MGMT-MIB DS0 情報。

MIB の詳細については、Cisco MIB ナビゲータを参照してください。

SNMP トラップの使用方法の詳細については、サポート対象の Cisco IOS SNMP トラップとその設定方法を参照してください。

CISCO-CALL-TRACKER-MIB

次の表は、コールがホストによって受信され、コール トラッカーがホストに SNMP トラップを送信するように設定されている場合に送信されるトラップを一覧し、説明しています。

[名前(Name)] 説明
1.3.6.1.4.1.9.9.9991.1.2.3.1.2 トラップのオブジェクト ID（OID）。
.x コールに割り当てられた ct_hndl。
=
Timeticks:(119447) 0:19:54.47 コール着信時のルータの稼働時間。

例 

Mar 12 06:27:00 
   localhost 
   snmptrapd[28977]: 
   172.22.35.14: 
   1.3.6.1.4.1.9.9.9991.1.2.3.1.2.1 = Timeticks: (119447) 0:19:54.47

このトラップはホスト172.22.35.14から送信され、コールに割り当てられたct_hndlは1です。ct_hndlを使用すると、SNMPセクションで説明されているように、アクティブテーブルからさらに情報をポーリングできます。コール着信時のホストの稼働時間は、Timeticks:(119447) 0:19:54.47 でした。

次の表は、コールがシステムによって、またはシステムからリリースされ、コール トラッカーがホストに SNMP トラップを送信するように設定されている場合に送信されるトラップを一覧し、説明しています。

[名前(Name)] 説明
1.3.6.1.4.1.9.9.9991.1.3.8.1.2 トラップの OID。
.x コールがアクティブだったときにコールに割り当てられた ct_hndl。
=
Gauge:1 履歴テーブルのコールに割り当てられたエントリ。

例 

Mar 12 06:27:21 
 localhost 
 snmptrapd[28977]: 
 172.22.35.14: 
 1.3.6.1.4.1.9.9.9991.1.3.8.1.2.1 = Gauge: 1

この例のトラップの原因はホスト172.22.35.14です。この場合の元のct_hndl番号は1で、履歴テーブル（戻される値）のエントリは1です。これらの番号は常に同じである必要がありますが、これは保証できません。「SNMP」の項で説明されているとおり、戻り値を使用して、履歴テーブルからコールに関する追加情報を取得できます。

関連情報

提供

  • aaron
    npanicke

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

Feedbackフィードバック

シスコに問い合わせ