ダイヤルとアクセス : 非同期接続

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

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

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

前提条件

要件

コール トラッカーおよび関連する機能を設定する前に、ネットワーク アクセス サーバのこれらのタスクを完了して下さい:

使用するコンポーネント

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

  • Cisco IOS(R) ソフトウェアリリース 12.1(3)T およびそれ以降

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

注: Cisco IOS ソフトウェア バージョンおよびプラットフォームがサポートをこの機能使用するかどうか確かめるのに Software Advisor登録ユーザのみ)を使用して下さい。 Software Advisor ツールの中では、コール トラッカーおよび ISDN/AAA の強化と指名される機能を捜して下さい。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

文書 の 表記法についての情報に関しては Ciscoテクニカル情報 規定を参照して下さい。

背景説明

コール トラッカーでキャプチャ される データはコール トラッカー データベーステーブルの内で維持され、簡易ネットワーク管理プロトコル(SNMP)、Command Line Interface (CLI)、または SYSLOG によってアクセス可能です。 セットアップ状態のすべてのアクティブ コールおよび呼び出しのためのセッション情報はアクティブなテーブルで切断された呼び出しのためのレコードはヒストリーテーブルに移動されるが、保存されます。 コール トラッカーは ISDN、ポイントツーポイントプロトコル (PPP)、Content Switch Module (CSM)、モデム、Exec、または TCP クリアのような関連サブシステムによって適当な呼出しイベントの知らせられます。 SNMPトラップは各コールのはじめにエントリがヒストリーテーブルで作成されるときエントリがアクティブなテーブルでおよび各コールの終わりに作成されるとき生成されます。 すべての呼び出し終了のための詳細な情報レコードを作成するコール レコード SYSLOG はコンフィギュレーションによって利用できます。 この情報は永久的なストレージおよび未来の分析のための Syslog サーバに送信 することができます。

覚えるべきいくつかのポイントはここにあります:

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

  • TCP システムはコール トラッカーに追加接続 情報を提供するために高められました。 その他の情報は下記のものを含んでいます:

    • 接続がなされなかった場合接続が確立された前に接続の試みが試みられたホストの数および識別、または総試行失敗。

    • 原因はアクティブセッション切断されています、または時間を計った前に原因はネットワーク アクセス サーバ ホストに接続しませんでした。

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

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

コールトラッカーの利点

このセクションはコール トラッカーの利点をリストします。

  • コール トラッカーはコール アクティビティの広範囲およびより簡単な実時間監視を提供します。

  • コール トラッカーはアクティブな、歴史的コール セッションのためのデータをキャプチャ し、SNMP、CLI、または SYSLOG によってそのデータにアクセスする外部アプリケーションを許可します。

  • コール トラッカーはコール管理デシジョンにボリューム および 使用統計を提供します。

  • コール トラッカーはより詳しい出力を提供するので改良し、modem call-record terse 機能を取り替えます。

    注: それらが同じような Syslog 出力を生成できるのでコール トラッカーおよび modem call-record terse を同時に有効に しない で下さい。 この操作は同一コールのための正副 2 通りに生じる場合がありますエントリ。

コール トラッカー 設定

コマンドの概略

リストされていること)コール トラッカーを設定するために、これらのコマンドを使用して下さい(順序で:

  1. enable

  2. configure terminal

  3. calltracker イネーブル

  4. calltracker コール レコード

  5. calltracker 履歴 max-size

  6. calltracker 履歴保最小値

  7. snmp-server はバイトカウントを packetsize

  8. snmp-server キューの長さ

  9. snmp-server enable traps calltracker

  10. snmp-server host ホスト コミュニティ ストリング calltracker

  11. calltracker タイムスタンプ ミリ秒(オプションの)

  12. モデム リンク情報ポーリング時間か spe リンク情報ポーリング モデム(オプションの)

  13. exit

詳しいコマンド

  コマンド 目的
ステップ 1: イネーブル例: Router>enable システム アドミニストレータが設定 する 特権EXECモードか他のどのセキュリティレベルも入力します。 プロンプト表示された場合パスワードを入力して下さい。
ステップ 2: configure terminal 例: Router#configure terminal グローバル コンフィギュレーション モードに入ります。
ステップ 3: calltracker イネーブル例: Router(config)# calltracker イネーブル NAS の有効コール トラッカー。
ステップ 4 calltracker コール レコード{簡潔な | 詳細表示} [静めて下さい]例: Router(config)# calltracker コール レコード 詳細表示静止 提供される情報はコール トラッカーのコール ヒストリ テーブルからの SNMP および SYSLOG によって収集することができます。 呼び出しを管理するのに主に使用するコール トラッカーの内の格納されているデータのサブセットが含まれている簡潔なオプションは要約一組のコール レコードを生成します。 冗長オプションは呼び出しをデバッグするのに主に使用するコール トラッカーの内で格納されているデータすべてが含まれているコール レコードの完全 セットを生成します。 静かなオプションによって、コール レコードは設定された Syslog サーバだけとないコンソールに送られます。
ステップ 5 calltracker 履歴最大サイズ数例: Router(config)# calltracker 履歴 max-size 50 ヒストリ バッファ(コールトラッカーヒストリーテーブルで保存される呼び出しエントリの最大数)を設定するために、calltracker ヒストリ最大サイズ数 コマンドを使用して下さい。 番号はコールトラッカーヒストリーテーブルで保存するべき呼び出しエントリの最大数です。 有効範囲は DS0 がある特定のプラットフォームでサポートした最大ゼロ〜 10 倍のです。 0 という値はどの履歴でも保存されることを防ぎます。 レポート タスクが高優先順位処理ではないので、そして利用可能 な CPU を待つ必要があるのでコール トラッカーは 1 分程コールが切断された後報告するためにかかることができます。 従って報告されるデータを保存するには十分に大きいように、ヒストリ バッファを設定して下さい。 バッファサイズを設定するとき、コールのコール 長さおよび型を(ISDN はモデムより短いです)考慮に入れ、次に 1 分期間受信することができる呼び出しの最大数を判別して下さい。 さらに、コール レートは設定 エラーかハードウェア障害が発生するとき発生する場合があります。 従ってプラットフォームのポートの数を 4 倍の使用することが、推奨されます。 詳細については、Cisco AS5300 および Cisco AS5800 のためのコール トラッカーおよび ISDN/AAA の強化を参照して下さい。
ステップ 6 calltracker 履歴保最小値例: Router(config)# calltracker 履歴保最小値 5000 分数をコールトラッカーヒストリーテーブルで呼び出しを保存するために設定 します。 分は呼び出しを保存する時間いっぱいです。 有効範囲は 0 〜 26,000 分です。 0 という値は呼び出しが保存されることを防ぎます。
ステップ 7 snmp-server はバイトカウント例を packetsize: Router(config)# snmp-server は 1024 を packetsize SNMP サーバが要求を受け取るか、または応答を生成するとき許可された最も大きい簡易ネットワーク管理プロトコル(SNMP) パケットサイズの制御を確立します。 バイトカウントは 484 から 8192 まで整数です。 デフォルトは 1500 です。
ステップ 8 snmp-server キューの長さ 長さ例: Router(config)# snmp-server キューの長さ 50 各トラップホストのためのメッセージ 待 ち 行列の長さを定義します。 トラップ メッセージが送信されるとき、Cisco IOSソフトウェアはキューを空にし続けます; ただし、それはキューを 4 つのトラップ メッセージ 毎秒の比率より速く空にしません。 デバイス ブートアップの間に、いくつかのトラップはデバイスのトラップ キュー オーバーフローが理由で廃棄することができます。 トラップは廃棄されていると考えれば、トラップ キューのサイズを増加できます(たとえば、100)にトラップがブートアップ 長さの間にそれから送信 することができたかどうか確認することはキューが空にする必要がある前に開かれる場合があるトラップ イベントの数を規定 する 整数です。 デフォルトは 10 です。
ステップ 9。 snmp-server enable traps calltracker 例: Router(config)# snmp-server enable traps SNMP 通知はトラップとして送信 されるか、または要求を知らせることができます; このコマンドはトラップをイネーブルに設定し、要求を知らせます。 このコマンド 制御(有効か無効)コール トラッカー CallSetup および CallTerminate 通知。 CallSetup 通知は各コールのはじめにエントリがアクティブなテーブルで作成される時生成され、(cctActiveTable)。 CallTerminate 通知は各コールの終わりにエントリがヒストリーテーブルで作成される時生成され、(cctHistoryTable)。
ステップ 10。 snmp-server host ホスト コミュニティ ストリング calltracker 例: Router(config)# snmp-server host ホスト コミュニティ ストリング calltracker 簡易ネットワーク管理プロトコル 通知オペレーションの受信者を規定 します。 SNMP 通知は、トラップまたはインフォーム要求として送信できます。 受信側はトラップを受信しても確認応答を送信しないので、トラップの信頼性は高くありません。 送信側は、トラップが受信されたかどうかを判断できません。 ただし、インフォーム要求を受け取る SNMP エンティティは SNMP 応答 プロトコル データユニット(PDU)が付いているメッセージを確認します。 送信側が応答をまったく受け取っていなければ、インフォーム要求を再送信できます。 このため、インフォームは、目的の宛先に到達できる可能性が高くなります。 トラップと比較されて、消費しますエージェントとネットワークのより多くのリソースを知らせます。 送信 されるとすぐ廃棄されるトラップとは違って、インフォーム要求はメモリで応答が受け取られるまたは要求時必要がありますまで保持する。 また、トラップは一度だけ送信 されます; インフォームは数回再試行されるかもしれません。 再送信の回数が増えるとトラフィックが増加し、ネットワークのオーバーヘッドが高くなる原因にもなります。 snmp-server host コマンドを入力しなければ、通知はまったく送信されません。 SNMP 通知を送信 するためにルータを設定するために少なくとも 1 つの snmp-server host コマンドを入力して下さい。 キーワードを付けずにコマンドを入力すると、すべてのトラップ タイプがホストで有効になります。 マルチプルホストをイネーブルに設定するために、各ホストのための個別のSNMPサーバ host コマンドを発行して下さい。 各ホスト宛てのコマンドに、複数の通知タイプを指定することもできます。 複数のSNMPサーバ host コマンドが同じホスト、また通知の種類のために(トラップはまたは知らせます)与えられる時、各々の次のコマンドは前のコマンドを上書きします。 last snmp-server host コマンドだけ有効になります。 たとえば、あるホストに snmp-server host inform コマンドを入力してから、同じホストに別の snmp-server host inform コマンドを入力したとします。その場合は、2 番目のコマンドが最初のコマンドと入れ替わります。
ステップ 11。 calltracker タイムスタンプ ミリ秒(オプションの)例: Router(config)# calltracker タイムスタンプ ミリ秒 アクセス サーバのコール レコード(CDR)のコール セットアップ時間のミリ秒の値を表示します。 このコマンドを実行しない場合、コール セットアップ時間は秒に表示する。

注: Cisco IOS Release 12.3(4) および 12.3(4)T だけによってこのコマンドを使用できます。

ステップ 12。 モデム リンク情報ポーリング時間(オプションの)または spe リンク情報ポーリング モデム(オプションの)例: Router(config)# モデム リンク情報ポーリング時間 320 有効コール トラッカー モデム の 詳細レコード。 任意で、モデム リンク情報ポーリング時間コマンドか spe リンク情報ポーリング モデムコマンドを使用できます。 これらのコマンドはアクティブ コールのためのリンク統計情報がモデムから取得されるポーリング間隔を設定 しました。 推奨されるポーリング時間値は 320 秒です。 MICA技術 モデムからコール トラッカーにリアルタイム呼び出し統計を有効に するために、modem link-info poll time コマンドを使用して下さい。

注: modem link-info poll time コマンドはかなりのメモリを、各 MICAモデム コールのためのおよそ 500 バイト消費します。 収集する特定のデータを必要とするときだけこのコマンドを使用して下さい。

ステップ 13。 終了例: Router(config)# 終了 現在のモードを終了します。

コールトラッカー出力

コールトラッカー出力は複数のレコードの間で分割されます。 この表はコールトラッカー出力レコードをリストし、記述したものです。

レコード 名 説明
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 アクティブ コールを扱うのにコール トラッカーが使用するコール トラッカー ハンドル A 固有の番号。 呼び出し 1 から 4,294,967,296 に識別(ID)数は割り当てられます。 これらの ID は 1 から開始し、1.によって増分します。 4,294,967,295 の呼び出しの後で、ID ラップおよび 4,294,967,296Th コールは 1.から開始する次の最も小さく利用可能 な数を受け取ります。 それはコールヒストリ、syslog および SNMP レコードのために可能性のある異なる呼び出しのための同じ ID 番号があるためにです。 これは数がアクティブ コールのためだけにユニークであるという理由によります。 ゼロは有効値ではないです。
サービス サービス タイプはコールの最後の既知のサービス サービス・タイプを報告します。
  • なし–コールと関連付けられるサービス無し
  • その他のサービス アクティブ、しかしこれらのどれも:
  • スリップ–シリアル ラインインターネットプロトコル
  • ppp – PPP
  • mp –マルチリンク PPP (RFC 1990)
  • tcpClear – TCP 上のバイト ストリーム
  • telnet – TELNET
  • exec –ターミナル サーバ
  • l2f –仮想 な プライベートデータネットワーク サービス(VPDN)その使用レイヤ 2 転送プロトコル
  • l2tp –仮想 な プライベートデータネットワーク サービス(VPDN)その使用 Layer 2 Tunneling Protocol
Origin コールがどのように作成されたか示します。
  • 起こして下さい–ダイヤルアウトは、コール ローカルで始められ、システムはセットアップ要求を送信 します。
  • 返事–ダイヤルインは、コール リモートで始められ、システムはセットアップ要求を受け取ります。
コール カテゴリ 可能性のある コール カテゴリーか型を表します。
  • なし–コールと関連付けられるコール カテゴリ無し
  • 他–これらのどれも:
  • モデム–モデムコール
  • isdn 同期化–今 syncData にマッピング される ISDN 同期化デジタルコール
  • v110 – V110 コール
  • v120 – V120 コール
  • cas デジタル–チャネル連携信号 (CAS) 56K データ呼び出し
  • mgcpData –今 syncData にマッピング される MGCP データ呼び出し
  • syncData –コール制御のための同期化デジタルデータ コール
  • LAPB TA – LAPB または LAPB-TA コール
DS0 スロット/cntr/chan コールが含まれているエントリ Slot/Port/DS0 DS0 リンク。 これは単一 物理ポート内の複数の DS0s のより大きいグループの内で含まれている DS0 であるかもしれません。
着信 被呼加入者 ID このコールのための呼出された電話番号。 システムによって応答される呼び出しに関してはこれはダイヤル番号識別(DNIS)に対応します。 システムによって送信される呼び出しに関してはこれは宛先番号です。 使用不可能これは長さゼロの文字列です。
発信 コーリングパーティ ID このコールのための呼出す電話番号。 システムによって応答される呼び出しに関してはこれは呼出す識別(CLID)に対応します。 システムによって送信される呼び出しに関してはこれはデバイスによって関連付けられる数です。 インターワーキング コールに関しては、これはダイヤル プランと関連付けられる送信コールのための変換規則がある場合、変換された発番号です。 使用不可能、これは長さゼロの文字列です。
リソース スロット/ポート コールに割り当てられる処理リソースのリソース スロット/ポート 識別。
USERID 利用できなかったらユーザ名 ID ユーザ ログイン ID か長さゼロの文字列。 これがゼロ以外の長さ ストリングを示し、cctHistoryUserValidationTime がゼロなら場合、ユーザは検証失敗しました
IP IP アドレスこのコールに割り当てられる IP アドレスか 0.0.0.0 適用されないならか利用できない。
マスク IP サブネット マスクこのコールに割り当てられる IP サブネット マスクか 0.0.0.0 適用されないならか利用できない。
アカウント ID AAA によってこのコールに割り当てられるアカウンティングセッション ID アカウンティングセッション 識別。 セッションID は Acct セッション ID アトリビュートとして AAA に RADIUS か task_id として TACACS+ によって送信 されます。 アカウンティングセッション ID が割り当てられない場合、値はヌルストリングです。
セットアップ コールがシステムに最初に発表されたセットアップ時間 タイムスタンプ。
conn コールが接続することができるようにそれが奪取 した秒の接続時間時間。
phys より高いプロトコル レイヤが始まることができるように物理層が定常 状態を実現させることができるおよびコールは準備ができていますようにそれが奪取 した秒の物理層準備ができた時間。 コールのためのモデムコールの場合には、物理層はデータ レート、変調およびエラー修正プロトコルが発生および応答モデムの間でネゴシエートされたら定常 状態を実現させます。 それはまた適応性がある比率 テクノロジーを使用する V.110 および V.120 のようなデジタルコールに適用します。
srvc サービス 時間 サービス タイプを識別するためにそれがかかった時間。
Auth このコールと関連付けられるユーザー 識別記号を検証するためにそれが奪取 した秒の認証時間時間。
init rx/tx b 比率 このコールのための最初のレシーブ/送信する ビットレート頭文字レシーブおよび送信する データ レート。 コールが ISDN 同期化のような同期デジタルコールである場合、この値は B チャネルのデータ レートです。 コールが非同期である場合、ISDN のような同期伝送 メディアを使用しても、値はビット/秒の MICA か Nextportモデムによってネゴシエートされる速度です。 この値はデータ レートがコールの間に変わっても、変更しません。 この値は初期データ比率が判別されるまでゼロです。
rx/tx 文字 送信/受信バイト コールで送信されるバイト数。 すべての未加工バイトは考慮されます。 この値はないかもしれないしまたはそうではないかもしれないプロトコル ヘッダが含まれています。 プロトコル ヘッダはあるかどうか決まりますサービスの値によって。
時刻 コールが接続される秒の接続される時間時間。 これはシステムが始まるとき初期セットアップ 要求へ、検出からの秒の通話 時間、または呼び出し終了の知らせられます。
ディスク サブシステム 始まるサブシステム IOS サブシステム、検出を切って下さい、または呼び出し終了の知らせられます。 サブシステム型:
  • admin
  • csm
  • isdn MICA
  • なし
  • ppp
  • RPM (Resource Pool Management)
  • VPN (仮想 な プライベート ネットワーク)
  • vtsp (音声 テレフォニー)

    注: 一般ユーザが所有しているよりこの情報が Cisco IOSソフトウェアのより多くのナレッジを必要とするが、それは接続に関する問題を解決するための Cisco テクニカルサポート担当者に役立ちます。

ディスク コード 切断原因 コード コードは原因をこのコール示す終わりました。 詳細は、次のドキュメントを参照してください。
ディスク テキスト 提供される接続解除 の 原因を記述する説明テキストを切って下さい。 これはテキストが利用できない場合長さゼロの文字列であるかもしれません。 詳細は、次のドキュメントを参照してください。

*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 アクティブ コールを扱うのにコール トラッカーが使用するコール トラッカー ハンドル A 固有の番号。 呼び出し 1 から 4,294,967,296 に識別(ID)数は割り当てられます。 これらの ID は 1 から開始し、1.によって増分します。 4,294,967,295 の呼び出しの後で、ID ラップおよび 4,294,967,296Th コールは 1.から開始する次の最も小さく利用可能 な数を受け取ります。 それはコールヒストリ、syslog および SNMP レコードのために可能性のある異なる呼び出しのための同じ ID 番号があるためにです。 これは数がアクティブ コールのためだけにユニークであるという理由によります。 ゼロは有効値ではないです。
prot: 最後 エラー修正プロトコル: 最後のレポートは使用中の既知 Error Correction (EC) プロトコルを持続させます。 EC プロトコル:
  • 標準(EC 提供無し)
  • 直接
  • mnp
  • lapmV42
  • syncMode
  • asyncMode (標準と EC 提供無し、同じ)
  • ara1 (1.0) ARA
  • ara2 (2.0) ARA
  • 他(識別されるそれら以外の EC プロトコル)
prot: attempt エラー修正プロトコル: 試みられる最初に試みられる Error Correction (EC) プロトコルを報告します。 prot を参照して下さい: 可能性のある EC プロトコルのために持続させて下さい
comp: 最後 圧縮プロトコル: 最後終了するコールの前に使用中の最後の圧縮プロトコルを報告します。 圧縮プロトコルは下記のものを含んでいます:
  • どれも(データ圧縮提供無し)
  • v42bisTx (伝送 方向だけの V.42bis)
  • v42bisRx (受信 方向だけの V.42bis)
  • v42bisBoth (レシーブおよび伝送 方向の V.42bis) mnp5
  • v44Tx (伝送 方向だけの V.44)
  • v44Rx (受信 方向だけの V.44)
  • v44Both (レシーブおよび伝送 方向の V.44)
comp: 補足 圧縮プロトコル: サポートされたかもしれないサポートされた圧縮プロトコル。 comp を参照して下さい: 可能性のある 圧縮プロトコルのために持続させて下さい
std: 最後 規格: 最後これは終了するコールの前に使用中の最後の変調規格です。 変調規格は下記のものを含んでいます:
  • 他(識別されるそれら以外の変調)
  • bell103a
  • bell212a
  • v21
  • v22
  • v22bis
  • v32
  • v32bis
  • vfc
  • v34
  • v17
  • v29
  • v33
  • k56flex
  • v23
  • v32terbo
  • v34plus
  • v90
  • v27ter
  • v110
std: attempt 規格: クライアント側のモデムによって試みられる試みられた変調規格。 std を参照して下さい: 可能性のある 変調規格のために持続させて下さい
std: init 規格: クライアント側のモデムによって試みられる最初変調規格に署名して下さい。 std を参照して下さい: 可能性のある 変調規格のために持続させて下さい
std: snr 規格: Signal to Noise Ratio 望ましい信号対雑音の比率測定単位。 この値は 0 から 1 dB ステップの 70 dB および変更まで及ぶことができます。 28.8 キロビット/秒接続が約 37 dB の SNR を要求することに注目して下さい。 接続のこれおよび品質が減少するより下げて下さい。 33.6 キロビット/秒接続は 38 から 39 dB の SNR を要求します。 また「はっきりした」行に約 41 dB の SNR があることに注目して下さい。
std: スクエア 規格: 0 が最も悪いおよび 3 定常ですある特定のビットレートのための回線 品質の信号品質メジャーは。 1 つか 2 つがある場合、モデムは低いレートに移る必要があります。 同様に、スクエア値が 4 から 7 なら、モデムスピードは高速まで移ります。 スクエア値が高ければ(たとえば、7)およびビットレートは低いです、リモート エンド レシーバに問題があるかもしれません。
rx/tx: 焦げます 受け取られる/送信される: 文字 コールで送信されるバイト数。 すべての未加工バイトは考慮されます。 この値はないかもしれないしまたはそうではないかもしれないプロトコル ヘッダが含まれています。 プロトコル ヘッダはあるかどうか決まりますサービスの値によって。
欧州共同体: rx/tx 受け取られる/送信される: エラー修正 フレーム受信されたおよび送信される EC 帯の数。
欧州共同体: rx 悪い状態 エラー修正: 受け取った悪い状態はエラーがあった EC 帯の数をフレーム化します。
rx/tx b 比率: 最後 ビットレート な レシーブ/送信する: コールが終わった場合の最後レシーブおよび送信する ビットレート。
rx/tx b 比率: 低 ビットレート な レシーブ/送信する: 下位コールの間に見つけられる最も低いレシーブおよび送信する ビットレート。
rx/tx b 比率: 高 ビットレート な受け取られる/送信する: 高いコールの間に見つけられる最も高いレシーブおよび送信する ビットレート。
rx/tx b 比率: 望クライアント ビットレート な レシーブ/送信する: クライアントが維持したいと思ったことクライアント 送信するおよびレシーブ ビットレート望まれる。 これがホストとしてホスト レポートが、取り扱うために上下にトレインしないかもしれないビットレート常にではないことは可能性のあるです。
rx/tx b 比率: 望ホスト ビットレート な レシーブ/送信する: ホスト 送信するおよびレシーブ ビットレート望まれたホストによって望まれてホストは維持したいと思いました。
retr: ローカル リトレイン: ローカルで始められるリトレインのローカル 番号。
retr: リモート リトレイン: リモートモデムによって始められるリトレインのリモート番号
retr: 失敗 リトレイン: 失敗したリトレインの壊れる数。
速度シフト: up/down ローカル 速度シフト: ローカル Up/Down 数はのまたはローカルモデムによって始められるシフト高速化します。
速度シフト: リモート up/down 速度シフト: リモート Up/Down 数はのまたはリモートモデムによって始められるシフト高速化します。
速度シフト: 失敗 速度シフト: 失敗した速度シフトの壊れる数。
v90: 統計 コールの前の V90 の V.90 ステータス ステータスは終わりました。 可能 な ステータス 値は下記のものを含んでいます:
  • 試み無し
  • 成功
  • 失敗
v90: クライアント V.90: V.90 クライアント側のモデムによって使用されるクライアント チップセット。
  • 該当なし
  • Unknown
  • ロックウェル
  • USR
  • ルーセント
  • PCtel
v90: 失敗 V.90 失敗 V.90 失敗。 V.90 失敗は下記のものを含んでいます:
  • なし
  • clientNonPCM
  • clientFallback
  • serverV90Disabled
time(sec) コールがどの位持続したか時間(秒)。 この値はトレインアップまたは認証の結果に関係なく常に戻ります。
ディスク原因 接続解除 の 原因 ASCII コードはコールを切断する MICA か Nextportモデムによって供給しました。 詳細は、次のドキュメントを参照してください。

*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 アクティブ コールを扱うのにコール トラッカーが使用するコール トラッカー ハンドル A 固有の番号。 呼び出し 1 から 4,294,967,296 に識別(ID)数は割り当てられます。 これらの ID は 1 から開始し、1.によって増分します。 4,294,967,295 の呼び出しの後で、ID ラップおよび 4,294,967,296Th コールは 1.から開始する次の最も小さく利用可能 な数を受け取ります。 それはコールヒストリ、syslog および SNMP レコードのために可能性のある異なる呼び出しのための同じ ID 番号があるためにです。 これは数がアクティブ コールのためだけにユニークであるという理由によります。 ゼロは有効値ではないです。
rx/tx levl レシーブ/送信する場合のレシーブ/送信する レベル レシーブ/送信する レベル電源は 0 から dBm ステップの -128 まで、及びます。 通常米国の範囲は約 -22 dBm、ヨーロッパの -12 dBm です。 よい範囲は -12dBm から -24dBm にあります。 詳細については、次のサイトを参照してください。 モデムの送受信レベルの理解
フェーズjit: freq フェーズジター: 2 つの場合ポイント間の周波数ピーク・ツー・ピーク差分(ヘルツで)。 ベースバンド 直交振幅変調 (QAM) コンステレーションの「動揺」のように取り消されなかった見えではないフェーズジター。 外ポイントのより長い円弧が付いている円弧のようにポイント見え。
フェーズjit: levl フェーズジター: フェーズジターの水平で水平な量は測定し、大きい「動揺が」次数にどのようにあるか示します。 オシロスコープで、コンステレーション ポイントは三日月形月のように見えます。 値は及ぶことができます 15 度まで。 一般的な値はゼロです(すなわち、フェーズジターは普通ありません)。
遠端エコーlevl 長い接続上の遠端エコー レベルは 2-wire-to-4-wire および 4-wire-to-2-wire ハイブリッド 回路のインピーダンス ミスマッチによって、エコー 生成 されます。 終端エコー レベル(リモートモデム アナログ フロント エンドの跳ねた送信 された アナログ信号のその部分は) 0 から dBm の -90 まで及ぶかもしれません。
freq offst 周波数オフセット期待された RX 搬送波周波数と実際の RX 搬送波周波数の違い(ヘルツで)。
フェーズ ロール フェーズ ロール フェーズ ロールはエコー場合もどって来に影響を与えます。 ある特定のコンステレーション パターンはモデムから送信 され、セントラル オフィスにで着きます。 この場合/コンステレーション パターンのエコーされた形式は送返されます。 ただし、コンステレーション図形は 0 から 359 度に回るかもしれません。 このローテーションはフェーズ ロールと呼ばれます。
ラウンド トリップ ラウンドトリップ遅延 リンクの総ラウンド トリップ 伝搬遅延(ミリ秒で)。 これは適切なエコー 消去のために重要です。 遅延がネットワークで変える量。
D パッド デジタルパッド デジタル パディング値。
D パッド 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 つが robbedビットが付いている PCM サンプルを表示する定期的な RBS パターンを示します。
定数 コンステレーションはこれコンステレーションのポイントの数です。
  • 0xFF = 無効
  • 1 の = 4 ポイント
  • 2 の = 16 ポイント
rx/tx: sym 比率 レシーブ/送信する: シンボルレート 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 アクティブ コールを扱うのにコール トラッカーが使用するコール トラッカー ハンドル A 固有の番号。 呼び出し 1 から 4,294,967,296 に識別(ID)数は割り当てられます。 これらの ID は 1 から開始し、1.によって増分します。 4,294,967,295 の呼び出しの後で、ID ラップおよび 4,294,967,296Th コールは 1.から開始する次の最も小さく利用可能 な数を受け取ります。 それはコールヒストリ、syslog および SNMP レコードのために可能性のある異なる呼び出しのための同じ ID 番号があるためにです。 これは数がアクティブ コールのためだけにユニークであるという理由によります。 ゼロは有効値ではないです。
一般的な情報 概要概要ポートウェア 情報。
rx/tx link-layer レシーブ/送信する Link-layer link-layer 受け取られるか、または送信された。
NAK 確認されなかった受け取られ、送信された LCP メッセージの NAK 総数。
rx/tx ppp スリップ レシーブ/送信する PPP-SLIP PPP の数および受信されたか、または送信されるスリップ帯。
悪い ppp スリップ 悪い PPP-SLIP 受信されたか、または送信される悪い PPP およびスリップ帯の数。
proj 最大 rx b 比率: クライアント ビットレート な写し出された最大レシーブ: クライアントはクライアントのための最大レシーブ ビットレートを写し出しました。
rproj 最大 rx b 比率: ホスト ビットレート な写し出された最大レシーブ: ホストはホストのための最大レシーブ ビットレートを写し出しました。
rx/tx: 最大 neg I フレーム レシーブ/送信する: 最大は I フレームをネゴシエートしました。 フレームの最大によってネゴシエートされる値を送受信して下さい。
rx/tx: neg ウィンドウ レシーブ/送信する: ネゴシエートされたウィンドウ 送信するおよびレシーブ ネゴシエーション ウィンドウ。
T401 タイムアウト T401 タイムアウトは有効に なる V.42 EC のクライアントへの接続を確立し、CSM からのデータを渡します。 転送が正常だった後データが渡される再度前に統計情報を問い合わせれば。 統計情報は増分するべきではありません。
tx ウィンドウ閉鎖 送信する ウィンドウ閉鎖はクライアントへの接続を確立し、CSM からのデータを渡します。 統計情報はウィンドウがクライアント側のモデムから ACK/NAK を閉じ、受け取らなければその時だけ増分します。 期待された結果は 0 を示す必要があります。
rx オーバーラン 受け取ったオーバーランの受け取ったオーバーラン総数。
retrans 帯 始められるリトレイン帯合計リトレイン帯。
v110: よい rx V.110: 受信された v110 よい帯の受信されたよい数。
v110: rx 悪い状態 V.110: 受信された v110 悪い帯の受信された悪い数。
v110: tx V.110: 送信される v110 帯の送信された数。
v110: 失われる同期化 v110: 失われる同期。 回数 v110 同期は失われます。
ss7/cot Signaling System 7(SS7) および Continuity Test (COT)統計情報。
v42bis サイズ: dict V.42bis サイズ: 辞書は v42bis 辞書 サイズを提供します。
テストは誤ります 見つけられる Test エラー自己テスト エラー。
リセット Reset 値 リセットDSP。
v0 同期化損失 V.0 同期損失確立するはクライアントが付いている接続クエリが 0 を示すことを確認し。 カウンターはリトレインを引き起こす 受信 シグナルで失われます V0 同期化しか増分しない必要があります。
失われるメール: ホスト 失われるメール: 失われるホスト メールのホスト番号。
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 アクティブ コールを扱うのにコール トラッカーが使用するコール トラッカー ハンドル A 固有の番号。 呼び出し 1 から 4,294,967,296 に識別(ID)数は割り当てられます。 これらの ID は 1 から開始し、1.によって増分します。 4,294,967,295 の呼び出しの後で、ID ラップおよび 4,294,967,296Th コールは 1.から開始する次の最も小さく利用可能 な数を受け取ります。 それはコールヒストリ、syslog および SNMP レコードのために可能性のある異なる呼び出しのための同じ ID 番号があるためにです。 これは数がアクティブ コールのためだけにユニークであるという理由によります。 ゼロは有効値ではないです。
v8bis キャップ V.8bis 機能。 機能は hex で表される V.8bis の間に受け取られてリストします。 これらのビットに関する詳細については ITU-T V.8bis を参照して下さい。
v8bis mod_sl V.8 Bis モード Select Mode hex で表された V.8bis の間に選択しました。 これらのビットに関する詳細については ITU-T V.8bis を参照して下さい。
V8 jnt メニュー hex で表される V.8 の間に交換される V.8 接合箇所メニュー接合箇所メニュー。 これらのビットに関する詳細については ITU-T V.8 を参照して下さい。
V8 Call Menu hex で表される V.8 の間の V.8 Call Menu Call Menu exchangeV.8 Call Menu。 これらのビットに関する詳細については ITU-T V.8 を参照して下さい。
v90 トレイン Hex の V.90 トレインの V.90 トレイン表示。
v90 sgn-ptrn V.90 サイン パターン V.90 サイン パターン。
状態 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 をリストし、記述したものです。

名前 説明
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トラップを送るために設定されるとき送信 されるトラップをリストし、記述したものです。

名前 説明
1.3.6.1.4.1.9.9.9991.1.2.3.1.2 トラップの Object 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トラップを送るために設定されるとき送信 されるトラップをリストし、記述したものです。

名前 説明
1.3.6.1.4.1.9.9.9991.1.3.8.1.2 トラップの OID
.x アクティブだった場合のコールに割り当てられる ct_hndl。
=
ゲージ: 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 セクションに記述されているようにヒストリーテーブルからコールについてのより詳しい 情報を得るために戻る数を使用できます。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 25221