音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

Cisco CallManager リリース3.0(x) のためのCisco IP Telephony トラブルシューティングガイド

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


目次


概要

このトラブルシューティングガイドは Cisco CallManager リリース 3.0(1) を設定し、監視し、解決するのに使用されるツール および ユーティリティを Cisco IOS 説明しますか。 ゲートウェイおよびゲートキーパー。 このドキュメントでは、3 つの異なるコール フローの詳細な例を示し、さらにコンセプトを説明するためにケース スタディを提供します。

最初のケース スタディでは、1 つのクラスタ内で Cisco IP Phone から別の Cisco IP Phone をコールします(クラスタ内コール)。 第 2 のケース スタディでは、Cisco IP phone から Cisco IOS ゲートウェイを経由して、ローカル PBX を介して接続している電話機または公衆電話交換網(PSTN)上の電話機をコールします。 第 3 番目のケース スタディでは、Cisco IP Phone から別のクラスタの別の Cisco IP Phone をコールします(クラスタ間コール)。

コール フローとデバッグ トレースを理解すると、問題を特定し、どのコンポーネントが問題の原因になっているのかを判断することが簡単になります。 このドキュメントでは、潜在的な問題をトラブルシューティングするツールについて説明します。 また、コール トレースおよびデバッグ出力がコール フローおよび一連のイベントを理解するのにどのように役立つかを説明します。

Cisco Technical Assistance Center (TAC)に連絡する必要があるイベントでは、ここで説明されているツールの多くが TAC から要求されるデータを収集する道具になります。 TAC に連絡する前にこのデータを収集していれば、問題解決は速くなります。

前提条件

要件

ネットワーク トポロジに適切なドキュメントがあることを確認するために次のチェックリストを活用してください。

  • すべてのネットワーク デバイスおよび重要なコンポーネント、およびそれらの機器が接続されているポート番号/インターフェイス番号と VLAN が属するポート番号/インターフェイス番号(該当する場合)を表示するトポロジ。 トランキング モードまたはチャネリング モードにあるポートには特定の宛先を使用する必要があります。

  • スパニングツリーのルートを設定し、すべての正常ブロッキング ポートが識別される必要があります。

  • どの WAN 回線も帯域幅(フレームリレーの場合は CIR)の量が識別される必要があります。

Cisco IP Phone 7960 には 10/100 スイッチド ネットワーク ポートおよび 10/100 PC ポートがあります。 シスコでは、PC ポートでの電話機の「カスケード」をサポートしません。 シスコでは、1 つのスイッチにネットワークと PC ポートの両方を接続することは推奨しません(これにより、ネットワークで物理ループが作成されます)。

すべての WAN は輻輳の発信源であるため、WAN のインターフェイスには特別な考慮が必要です。 Cisco IP Phone およびゲートウェイはリアルタイム トランスポート プロトコル(RTP)優先順位フィールドを 5 に設定しますが、これは RTP パケットをタグ付けするだけです。 Voice over IP (VoIP)のトラフィックが最小の遅延とリソース競合でサービスされるようにネットワークの優先順位付けとコール アドミッション制御が設定されるかどうかは、ネットワーク管理者しだいです。 このトピックの詳細については、以下を参照して下さい。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

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

このドキュメントのすべての説明は、特記されていない場合は Cisco CallManager Release 3.0(1) についての記述です。

表記法

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

背景説明

トポロジ

VLAN、ルータ、スイッチ、ゲートウェイなどのに接続されているポートなどのさまざまなコンポーネントが接続されたポートを含む正確なネットワーク トポロジを保持している必要があります。 きちんと文書化されたトポロジは、システムに問題をトラブルシューティングする場合に役立ちます。 Cisco CallManager で管理するすべてのネットワーク デバイスとターミナル サービスへのアクセスを使って正確なトポロジであることを確認してください。

新規または既存のネットワークに IP テレフォニーを追加するには注意深い計画が必要です。 リアルタイム トラフィックはデータ トラフィックとは異なる要件があるため、ネットワークは低遅延および Quality of Service (QoS)に注意して設計する必要があります。 ミッション クリティカルなトラフィックを転送するすべてのネットワークと同様に、ネットワーク管理者が正確で詳細なネットワーク トポロジのダイアグラムを維持することが必ず必要です。 危機的状況では、ネットワークの全体の概要だけでなく、どのポートがネットワーク コンポーネント(ルータ、スイッチ、 Cisco CallManager サーバ、ゲートウェイ、およびその他の重要なデバイス)に接続されているかを理解することが重要です。 冗長性およびスケーラビリティを指揮してネットワークを計画することが重要です。

注意 注意: シスコでは、スイッチに共有接続のハブを使用することはサポートしていません。 ハブによって IP テレフォニー システムの通常の動作が妨げられることがあります。

スイッチド ネットワークを使用する場合、スパニング・ツリー(冗長構成用)の状態を知ることが重要です。 ネットワークの状態は問題が発生する前に記録されている必要があります。

用語集

次の表は、このドキュメントで使用する可能性のある一般的な用語と略語を示します。

用語集
略語/用語 定義
..cnf デバイスで使用されるコンフィギュレーション ファイル。
??-関連法規(「mu-law」) 北米で一般的に使用されるコンパンディングの技法。 ?-関連法規は ITU-T G.711 の 64 キロビット/秒 コーデックとして標準化されます。
A-law パルス符号変調(PCM)システムでアナログ信号とデジタル信号間の変換に使用される ITU-T のコンパンディングの標準。 A-law はヨーロッパ電話回線網で主に使用され、北米人に類似したですか。-関連法規規格。
ACF アドミッション確認
ANI 発信者番号
ARQ アドミッション要求
B チャネル ベアラー チャネルです。 ISDN では、これはユーザ データの送信に使用する全二重の 64 kbps チャネルです。
Calling Search Space コーリング サーチ スペースは、特定のデバイスがコールできる電話番号コールとルート パターンを定義します。 これは、コールを行う際に参照されるパーティションのグループです。 たとえば、「Executive」という名前のコーリング サーチ スペースに複数のパーティションがあるとします。 この例では、Cisco IP Phone 番号は「Executive」コーリング サーチ スペースにあります。 コールを開始すると、Cisco IP Phone 番号は「NYInternationalCall」、「NYLongDistance」、「NYLocalCall」、および「NY911」の使用可能なパーティションを介して検索します。 たとえば、「Guest」のコーリング サーチ スペースを持つ Cisco IP Phone 番号が、「NYLocalCall」および「NY911」パーティションを介する検索しかできないかもしれません。 したがって、ユーザが国際電話番号をダイヤルしようとした場合、一致する番号が見つからずコールがルーティングされません。
CCAPi コール制御 API VoIP のコール処理を処理するために Cisco IOS によって使用されます。
CCO Cisco Connection Online(http://www.cisco.com)。 シスコ製品、テクニカル サポート情報、テクニカル ドキュメントでの最新情報を提供します。
CDR 呼詳細レコード。 コール発信元、宛先、および期間に関する情報を提供します。 これが課金レコードを作成するために使用されます。
Cisco IOS CiscoFusion アーキテクチャの下で全製品に共通の機能、拡張性、セキュリティを提供するシスコ システム ソフトウェア。 Cisco IOS は、広範囲なプロトコル、メディア、サービス、プラットフォームをサポートしながら、インターネットワークの一元的で統合された自動的なインストールと管理を可能にします。
クラスタ Cisco CallManager クラスタ。 複数の Cisco CallManager サーバの論理グループ。
CMR コール管理レコード(CDR)。Diagnostic CDR として知られいます。 これには、送信されたバイト数、送信されたパケット、ジッター、を含むレコード、ジッター、遅延、廃棄されたパケットなどが含まれます。
コーデック コーダ/デコーダ。 音声信号の圧縮/復元に使用されるドメイン特定部分(DSP)ソフトウェア アルゴリズム。
D チャネル データ チャネル 全二重、16 kbps(BRI)または 64 kbps(PRI)の ISDN チャネル。 シグナリングおよび制御に使用されます。
DCF 確認を解除します。
DHCP Dynamic Host Configuration Protocol。 IP アドレスをダイナミックに割り当てるメカニズムを提供し、ホストがアドレスを必要としなくなった場合にそのアドレスを再利用できるようにします。
DN 電話番号。 これは、終端デバイスの電話番号です。 これは、ゲートウェイに接続された Cisco IP Phone、Cisco IP SoftPhone、ファックス機器、またはアナログ電話機に割り当てられた番号になります。 例は、1000 および 24231 などです。
DNIS 着信番号識別サービス。
DNS ドメイン ネーム システム。 これはネットワーク ノードの名前をアドレスに変換するためにインターネットで使用されるシステムです。
DRQ 接続解除要求
DTMF デュアル トーン多重周波数。 これは、電話をかけるために(タッチトーンなど) 2 つの同時音声帯域のトーンを使用することです。
フロー ネットワーク上の 2 つのエンドポイント間(2 台の LAN ステーション間など)を流れるデータのストリーム。 単一の回線上で複数のフローを転送できます。
フルデュプレックス 送信側ステーションと受信側ステーションの両方からの同時データ転送の機能。
G.711 64 kbps PCM の音声コーディングの技法を規定します。 G.711 で符号化された音声は、すでに PSTN または PBX でのデジタル音声配信用の正しい形式になっています。 これは、ITU-T 標準の G シリーズ勧告で規定されています。
G.729 音声が 8 kbps のストリームにコード化される符号励振線形予測(CELP)圧縮を規定しています。 この標準には 2 種類の方法(G.729 および G.729 Annex A)があり、主に計算の複雑度が異なります。 どちらも、32 kbps の適応差分パルス符号変調(ADPCM)と同程度の会話品質を提供します。 これは、ITU-T 標準の G シリーズ勧告で規定されています。
H.225 H.225 セッションの確立とパケット化を規定する ITU 標準。 H.225 は実際には複数の異なるプロトコルである、 RAS、Q.931 の使用、および RTP の使用を規定しています。
H.245 H.245 エンドポイントの制御を規定する ITU 標準。
H.323 ITU-T 標準 H.320 の拡張であり、LAN および他のパケットスイッチド ネットワーク上でのビデオ会議や、インターネット経由の映像配信を可能にします。
半二重 送信ステーションと受信ステーション間で、一度に 1 方向にのみデータ転送できる機能。 2 進データ同期通信(BSC)は、半二重プロトコルの一例です。
フックフラッシュ 電話機が PBX からのダイヤル トーンの再呼び出しを行うことを示すために、コール中に電話などのデバイスによって通常は生成される短いオン フック時間。 フックフラッシュはコール転送を実行するために頻繁に使用されます。
ICCP Intra-Cluster Control Protocol
ISDN サービス総合デジタルネットワーク。 電話交換網でデータ、音声、およびその他のソースのトラフィックの伝送が許可された電話会社によって提供される通信プロトコル。
ジッター 音声パケットの到着時間の変動。
MGCP メディア ゲートウェイ コントロール プロトコル。 VoIP ゲートウェイ(MGCP エンドポイント)を制御する Cisco CallManager のプロトコル。
MTP メディア ターミネーション ポイント
Partition パーティションは、電話番号(DN)および同様の到達可能性特性を持つルート パターンの論理グループです。 簡単に言えば、これらは通常は「NYLongDistance」、「NY911」などのようにその特性に対応する名前が付けられます。 DN またはルート パターンが特定のパーティションにある場合は、これによってそのデバイスまたはルート リストを誰が呼び出すことができるかというルールが作成されます。
PBX 構内交換機。 加入者の構内に設置されているデジタルまたはアナログの電話交換機。私設電話交換網や公衆電話交換網の接続に使用されます。
PRI 一次群速度インターフェイス。 一次群速度アクセスは、1 本の 64 Kbps D チャネルと、23 本(T1)または 30 本(E1)の音声またはデータ用 B チャネルから構成されます。
PSTN 公衆電話回線網。 世界中で使用されている各種の電話網およびサービスを示す一般用語。
Q.931 ISDN シグナリングを規定する ITU 標準。 H.225.0 標準は、H.323 セッションを確立および切断するための Q.931 の変形を使用します。
RAS Registration, Admission, and Status Protocol。 これは検出およびゲートキーパーとのやり取りに使う H.323 プロトコル スイートで使用されるプロトコルです。
ルートフィルタ ルート フィルタはかける電話番号の制限に使用できるだけでなく、ワイルドカード パターンのサブセットを識別するためにも使用できます(@ ワイルドカードを北米ダイヤル プランで使用する場合)。 たとえば、900 エリア コードの電話をかけることを防ぐために使用できます。 また、複合ルールを設定するためにパーティションおよびコーリング サーチ スペースとともに使用できます。 たとえば、3 ユーザ グループ、 Executive、Staff、および Guest を確立していると想定します。 ルート フィルタは、Executive ユーザグループには国際番号をかけることを、Staff ユーザ グループには市内番号または長距離電話をかけることを、そして Guest ユーザ グループには市内番号である 911 および 800 番だけをかけることを許可します。
ルート グループ ルート グループは、同等のアクセスとみなされた複数のゲートウェイまたはゲートウェイのポートのリストです。 これは従来の PBX の用語のトランク グループに似ています。 たとえば、任意に使用できる同じキャリアに 2 本の PRI 回線がある場合があります。 1 台のゲートウェイ(またはゲートウェイの特定の 1 ポート)は 1 つのルート グループにしか追加できません。
ルート リスト 以前はルート ポイントと呼ばれ、優先順位の順に設定されたルート グループのリストを介してハントするために Cisco CallManager が使用できるルート リストです。 複数のルートリストで同じルート グループを指定できます。
ルート パターン 特定の番号、または通常はある範囲の着信番号です。これは、デバイス(Cisco アクセス DT-24+ ゲートウェイまたは音声対応ルータなど)にまたは間接的にルート リストを介してコールをルーティングするために使用します。 たとえば、1XXX は 1000 ~ 1999 を示します。 1XXX の「X」は 1 桁を示す ワイルドカードです。 他にも同様のワイルドカードがあります(@、! など)。 ルート パターンはルート フィルタが同一でない限り、パーティション内で一義的である必要はありません。
RRJ 登録の拒否。
RTP リアルタイム トランスポート プロトコル、IPv6 プロトコルの 1つ。 RTP は、音声、ビデオ、シミュレーション データなどのリアルタイム データをマルチキャストまたはユニキャストのネットワーク サービスとして、アプリケーションがリアルタイムにデータを転送できるように、エンドツーエンドのネットワーク転送機能を提供するように設計されています。 RTP は、ペイロード タイプの識別、シーケンス番号付け、タイム スタンプ処理、配信のモニタリングなどのサービスをリアルタイム アプリケーションに提供します。
SEP Selsius Ethernet Phone。 この略語は、Cisco IP Phone の MAC アドレスの先頭に置かれ、一意のデバイス ID を表します。
無音圧縮(音声アクティビティ検出) 無音圧縮によって、Cisco IP Phone で音声がないことを検出し、ネットワーク上にパケットを送信しないようにできます。 音声品質はわずかに低下しますが、接続で低い帯域幅を使用する可能性もあります。 無音圧縮はデフォルトでは無効になっています。
SNMP 簡易ネットワーク管理プロトコル。 TCP/IP ネットワークでほぼ独占的に使用されているネットワーク管理プロトコル。 SNMP は、ネットワーク デバイスを監視および制御し、設定、統計値の収集、パフォーマンス、およびセキュリティを管理する手段を提供します。
SQL 構造化照会言語。 リレーショナル データベースの定義およびアクセスに使用される国際的な標準言語。
T1/CAS T1 は AMI または B8ZS のコーディングを使用して電話交換網を介して 1.544 Mbps で DS 1 フォーマットに作成したデータを送信するデジタル WAN 通信事業者の設備です。 CAS は個別線信号方式インターフェイスです。
T1/PRI T1 は AMI または B8ZS のコーディングを使用して電話交換網を介して 1.544 Mbps で DS 1 フォーマットに作成したデータを送信するデジタル WAN 通信事業者の設備です。 PRI は一次群速度インターフェイスです。 一次群速度アクセスは、1 本の 64 Kbps D チャネルと、23 本(T1)または 30 本(E1)の音声またはデータ用 B チャネルから構成されます。
TCP Transmission Control Protocol(伝送制御プロトコル) これは、コネクション型のトランスポート層プロトコルであり、信頼性の高い全二重データ伝送を提供します。 TCP は TCP/IP プロトコル スタックの一部です。
TFTP Trivial File Transfer Protocol(トリビアル ファイル転送プロトコル) 簡易バージョンの FTP です。これにより、ネットワークを介して 2 つのコンピュータ間でファイルを転送することができます。
トランスレーション パターン コールをルーティングする前のコールされた(DNIS)およびコールしている自動番号識別(ANI)番号の変換に使用されます。 たとえば、コールが 2XXX の範囲にある複数の Cisco IP Phone に変換される必要のある一連の番号(919 392 - 3XXX)になる場合があります。 Cisco CallManager に 919 392 - 3XXX に設定されたトランスレーション パターンがあります。 このパターンは、先頭の 919 392 - 3 を単に 2 に変換し、残りの桁はそのまま残します。 これで、コールは適切な Cisco IP Phone にルーティングされます。 トランスレーション パターンは、実際の変換にのみ使用され、単純な桁の削除およびプレフィックス変換に使用することはできません。
UDP User Datagram Protocol(ユーザ データグラム プロトコル) UDP は、TCP/IP プロトコル スタックのコネクションレス トランスポート層プロトコルです。 UDP は、確認応答や配信保証なしでデータグラムを交換する単純なプロトコルです。エラー処理と再送信は、他のプロトコルで処理する必要があります。 UDP は RFC 768 で定義されています。
音声アクティブ化検出(無音圧縮) 音声アクティブ化検出によって、Cisco IP Phone で音声がないことを検出し、ネットワーク上にパケットを送信しないようにできます。 音声品質はわずかに低下しますが、接続で低い帯域幅を使用する可能性もあります。 VAD/無音圧縮は、デフォルトで無効になっています。
VoIP Voice over IP
VLAN 仮想 LAN。 実際には多数の異なる LAN セグメント上に存在しているが同じネットワークに接続されているように通信できるように設定(管理ソフトウェアを使用)されている 1 つ以上の LAN 上のデバイス グループです。 VLAN は物理接続ではなく論理接続に基づいているため、柔軟性がとても高い機能です。

Cisco CallManagerの監視およびトラブルシューティングに使用するツールおよびユーティリティ

このセクションでは、Cisco CallManager の設定、モニタ、トラブルシューティングを行うツールおよびユーティリティを示します。

Cisco CallManager Administration 詳細

Cisco CallManager Administration では、システム、データベース、およびその他のコンポーネントについてバージョン情報が提供されます。 開始ページで、[Details] ボタンをクリックにして、使用中ののバージョンをメモします。

ccm_admin.gif

Cisco CallManager Administration の詳細な説明については、『Cisco CallManager オンライン ドキュメント』を参照してください。

Microsoft パフォーマンス

パフォーマンス(モニタ)は、Cisco CallManager システムのアクティビティと状態を表示できる Windows 2000 Server のアプリケーションです。 これは、リアルタイムの汎用および特定の情報をレポートします。 すべての Cisco CallManager のインストールのシステムとデバイスの統計情報を収集して表示するために Windows 2000 のパフォーマンスを使用できます。 この管理ツールは、コンポーネントそれぞれの動作を調査しなくても、システムを完全に理解できます。

さまざまなシステム変数をリアルタイムでモニタするためにパフォーマンスを使用できます。 Cisco CallManager パラメータを追加した後、Cisco CallManager がシステムによって生成された統計情報をその下に表示する用語を定義できます。 たとえば、進行中のコール数をいつでもモニタでき、または現在特定のゲートウェイを通過するコール数をモニタできます。 パフォーマンスでは、リアルタイムで一般および Cisco CallManager 固有の両方のステータス情報が表示されます。

/image/gif/paws/30266/ms_perf.gif

Microsoft パフォーマンスの開始

Cisco CallManager を実行しているサーバ PC でパフォーマンスを開くには、[スタート] > [設定] > [コントロール パネル] > [管理ツール] > [パフォーマンス] の順にクリックします。

パフォーマンスのカスタマイズ

パフォーマンス モニタでは、モニタする Cisco CallManager 関連パラメータの表示をカスタマイズする必要があります。 表示に含めるオブジェクト、カウンター、およびインスタンスを選択します。 Microsoft パフォーマンスを CallManager 動作用にカスタマイズするためのオブジェクトとカウンタの使用方法の手順については、『Cisco CallManager, リリース 3.0 のリモート サービス性能の設定』を参照してください。

Microsoft イベントビューア

Microsoft イベント ビューアーは、 Windows NT サーバでのシステム、セキュリティ、およびアプリケーション イベント(Cisco CallManager を含む)を表示する Windows NT のサーバ アプリケーションです。 サービス(TFTP を含む)がデータベース(トレース設定を抽出するところ)を読み取ることができない場合、イベント ビューアーにエラーが追加されます。 イベント ビューアーは、このタイプのエラーが表示される唯一の場所です。 次の図は、 Windows NT サーバで実行するアプリケーション ログを表示します。

ms_event_viewer.gif

イベント ビューアーの起動

Cisco CallManager を実行しているサーバ PC でイベント ログを開くには、[スタート] > [設定] > [コントロール パネル] > [管理ツール] > [イベント ビューアー] の順にクリックします。 イベント ビューアーは、システム、セキュリティ、およびアプリケーションのエラー ログを表示します。 Cisco CallManager のエラーは、アプリケーション ログに記録されます。

イベントの詳細情報

ログのイベントをダブルクリックすると、イベントに関する詳細情報を表示できます。

/image/gif/paws/30266/event_prop.gif

SDI トレース

SDI トレースはローカル ログファイルです。 要求の発信元またはディスポジションをモニタするために SDI のトレースの確認する場合に、IP アドレス、TCP のハンドル、デバイス名、またはタイム スタンプを使用できます。 このデバイス名は、デバイス プールとモデルを表示するファイルの構築に追跡を戻せます。 デバイス プールとモデルを表示するファイル プロトタイプの構築に追跡が戻ることができます。このファイル プロトタイプは Cisco CallManager と TCP 接続ポートのネットワーク アドレスをリストします。

SDI トレースを観察するときは、C++ クラスとルーチン名がほとんどのトレース行に含まれていることを確認してください。 ほとんどのルーチンは、標準形式でのスレッド ID などの特定のリクエストのサービスに関連付けられています。

SDI トレースはケース スタディで詳細に説明します。

SDI のトレース出力

SDI トレースは Cisco CallManager のアクティビティのトレースを格納するファイル(たとえば、 CCM000000000)を生成します。 これらののトレースは、Cisco CallManager 初期化プロセス、登録プロセス、キープアライブ プロセス、コール フロー、番号分析、および Cisco IP Phone、ゲートウェイ、ゲートキーパーなどの関連デバイスに関する情報を提供します。 この情報は、Cisco CallManager をトラブルシューティングするときに問題を特定するために役立ちます。 必要な情報だけを正確に追跡するには、トレース設定インターフェイスのオプションの設定方法を理解することが重要です。

トレース ファイルは次のデフォルトの場所に保存されます。 C:\Program Files\cisco\bin 新しいトレース ファイルは、Cisco CallManager を再起動するたびに開始、または指定された行数に到達した場合に開始します。

次に、Cisco CallManager Administration のトレース設定インターフェイスを示します。 トレースを有効にし、必要な情報のレベルを選択し、必要なレベルの情報を取得するためにユーザ マスクを確認します。

/image/gif/paws/30266/trace_config.gif

トレースが正しく設定されていない場合、問題を特定することを非常に困難にする大量の情報が生成されます。 次の項では、有用なトレースを適切に設定する方法について説明します。

トレースの設定

トレースは、ユーザ マスクのフラグ(別名ビット)およびトレース レベルで構成されます。 Cisco CallManager Administration を開きます。 トレースをオンにするには、[Service] > [Trace] 画面のトレース パラメータ(設定済みのサービス、ビットなど)を設定します。 トレースの有効化/無効化および各設定済みのサービスのユーザ マスクとレベルに関する完全な情報については、『Cisco CallManager 管理ガイド, リリース 3.0(1)』を参照してください。

次は、特定の問題に基づいて有効になるトレース マスク ビットの 2 通りの例です。

  • 通常のメッセージをデバッグするためには、サブシステム ビット 5、6、7、8、11、および 12 をオンにします。

  • ゲートウェイのデバッグのためには、サブシステム ビット 3、4、5、6、7、8、9、11、12、および 13 をオンにします。

次は、特定の問題に基づいて必要なトレース レベルの 2 通りの例です。

  • 通常のデバッグをするためには、トレース レベルは SDI_LEVEL_ARBITRARY に設定する必要があります。

  • 正常に動作しているシステムでは、トレース レベルは SDI_LEVEL_ERROR に設定する必要があります。

SDL トレース

シスコのエンジニアはエラーの原因を探るために SDL トレースを使用します。 SDL のトレースに格納されている情報を完全に理解する必要はありません。 ただし、TAC と共同で作業している間は SDL トレースを有効にし TAC に情報を提供することを依頼されることがあります。 SDL のトレース ファイルはローカル ディレクトリ、Windows NT Event Viewer、および CiscoWorks 2000 に保存できます。 サーバのパフォーマンスの低下を避けるには、トレースのキャプチャが完了したら確実に SDL トレースをオフにするようにします。

SDL トレースではトレースおよびアラームのために C インターフェイスを提供しています。 アラームは、ファイル、データベース、Winsock にアクセスできない、または他のオペレーティング システムのリソースに割り当てることができないなどの予期しないイベントを管理者に通知するために使用されます。

SDL トレースの有効化

SDL トレースは、Cisco CallManager Administration の [Service] > [Service Parameter] の領域で有効にできます。 これらのトレースを有効にしなければならないのは TAC エンジニアによって要求された場合だけであることに注意してください。 次の図の SDL トレースをオンにするために選択した値に注意してください。

/image/gif/paws/30266/serv_param_config.gif

SDL トレースを有効にすると、トレースが収集されます。 トレースがローカル ドライブに送信される場合は、それらの情報を Cisco \Trace サブディレクトリ内で取得できます。 代わりに、トレース ファイルをイベント ログまたは CiscoWorks 2000 に送信できます。

次の表に示す SDL フラグ ビットは、Cisco CallManager Administration の [Service] > [Service Parameters] の領域で設定されます。 次は、特定の問題に基づいて必要な値の 2 通りの例です。

  • 通常のコールのデバッグの推奨値は SdlTraceTypeFlags=0x00000b04 です。

  • 低レベルのデバッグまたはゲートウェイのデバッグの推奨値は SdlTraceTypeFlags=0x00004b05 です。

SdlTraceTypeFlags の定義
SDLTraceTypeFlag 定義
traceLayer1 = 0x00000001 すべて レイヤ 1 トレース オン
TraceDetailLayer1 = 0x00000002 詳細 レイヤ 1 トレース オン
TraceSdlLinkAdmin = 0x00000004 クラスタ内の Cisco CallManager 間のリンクをトレース
traceUnused = 0x00000008 未使用
traceLayer2 = 0x00000010 すべて レイヤ 2 トレース オン
traceLayer2Interface = 0x00000020 レイヤ 2 インターフェイス トレース オン
traceLayer2TCP = 0x00000040 レイヤ 2 TCP トレース オン
TraceDetailLayer2 = 0x00000080 レイヤ 2 フレームの詳細なダンプ。
traceLayer3 = 0x00000100 すべて レイヤ 3 トレース オン
traceCc = 0x00000200 すべてのコール制御のトレース オン
traceMiscPolls = 0x00000400 その他のポーリングのトレース
traceMisc = 0x00000800 さまざまなトレース(データベース シグナル)
traceMsgtrans = 0x00001000 メッセージ変換シグナル(TranslateIsdnToSdlReq、TranslateIsdnToSdlRes、TranslateSdlToIsdnReq、TranslateSdlToIsdnRes)
traceUuie = 0x00002000 UUIE 出力 トレース オン
traceGateway = 0x00004000 ゲートウェイ信号

次の表に示すデータ ビットは、Cisco CallManager Administration の [Service] > [Service Parameters] の領域で設定されます。 次は、特定の問題に基づいて必要な値の 2 通りの例です。

  • 通常のシステムのデバッグの推奨値は SdlTraceDataFlags=0x110 です。

  • SDL リンクを使って問題を追跡する場合の推奨値は 0x13D(非圧縮のトレース。 圧縮したトレースを使用する場合は、ビット 0x200 を設定する必要があります。 これは、他のどのビットとも組み合わせて設定できます)。

SDLTraceDataFlags の定義
SDLTraceDataFlag 定義
TraceSdlLinkState = 0x001 SDL Link Initialization のトレースを有効にする
TraceSdlLowLevel = 0x002 低レベルの SDL イベント、fileOpen、およびソケットのイベントのトレースを有効にする(例)
TraceSdlLinkPoll = 0x004 SDL Link Poll メッセージのトレースを有効にする
TraceSdlLinkMsg = 0x008 SDL Link メッセージのトレースを有効にする
traceRawData = 0x010 未加工の信号データのトレースをすべての信号で有効にする
TraceSdlTagMap = 0x020 タグのマッピングを有効にする
traceCreate = 0x100 トレースを作成および停止するプロセスを有効にする
TraceNoPrettyPrint = 0x200 トレース ファイルの pretty プリントを無効にする

ディスク領域の警告

警告 警告: このインターフェイスから取得した情報が非常に詳細である可能性があり、このため大量のディスク領域を消費することに注意が必要です。 この理由で、シスコでは一定時間トレース ファイルをオンにし、情報を確認し、トレースをオフにすることをお勧めします。

スニファ トレース

スニファはネットワークの IP トラフィックをモニタし、トレースの形式で情報を提供するソフトウェア アプリケーションです。 スニファ トレースは、使用するネットワークでのネットワークの量とタイプに関する情報を提供します。 TCP/IP または UDP パケットは Cisco CallManager、および電話やゲートウェイなどのエンドポイント デバイスで使用されるプロトコルです。 スニファ トレースではまた、音声の問題やコールの切断などになる高レベルのブロードキャスト トラフィックを識別することができます。 共通のスニファのアプリケーションには、Network Associates SnifferPro、Hewlett-Packard Internet Advisor、および Acterna Domino などがあります。 Domino は、ハードウェアとソフトウェアのをスニファするソリューションおよびネットワーク アナライザを提供します。 Domino を使用する場合、キャプチャされたスニファ ファイルを評価する分析ソフトウェアを使用すること(SnifferPro アプリケーションからなど)を推奨します。

コール詳細レコード (CDR) および コール管理レコード (CMR)

CDR は、Cisco IP Phone からかけられた(またはしました)任意のコールのログを記録するレポート オプションです。 CDR には、 基本 CDR および Diagnostic CDR(または CMR)の 2 種類があります。 有効ににすると、SQL Server Enterprise Manager で CDR または Diagnostic CDR(CMR)を開くことができます。 CDR ファイルは、Microsoft Access や Excel などのほとんどのアプリケーションにエクスポートできる SQL データベースに保存されます。

CDR レコードには、課金レコードを生成するために必要な情報が含まれています。 分散環境では、すべての CDR データは、中央の場所、または一組の場所に収集されます。 Cisco CallManager ノードの障害によって、使用できないノードと関連付けられた CDR データは作成できません。 データはフラット ファイルとして Cisco CallManager ディスクでは保存されていませんが、代わりに中央データベースに表形式で保存されます。

レコードが書き込まれる前に Cisco CallManager に障害が発生すると、コールのレコードはありません。 これは、Cisco CallManager でアクティブなコールが終了する前にその Cisco CallManager で障害が発生すると、そのコールに対するレコードが書き込まれないことを意味します。

CDR および CMR に関する詳細については、このドキュメントの「コールの詳細な記録」の項を参照してください。

提供される情報は次のとおりです。

  • レコードの読み出しおよび書き込み

  • 既知の問題

  • 生成されるレコード タイプのリスト

  • 各レコードのフィールドおよびそのフィールドが何を表すかの説明のリスト

  • 記録されるコールのタイプおよびそれらのタイプで記録されるフィールドの説明

  • CDR レコードに表示される可能性のある原因コードのリスト

CDR の有効化または無効か

CDR レコードの作成は、システムがインストールされたときはデフォルトで無効になっています。 CDR データを保持する場合は、 Cisco CallManager Administration で [Service] > [Service Parameters] の領域で CDR を有効にします。 CDR 処理はシステムの動作中に、いつでも有効および無効にすることができます。 有効または無効にした CDR を実際に機能させるために Cisco CallManager を再起動する必要はありません。 システムは、数秒内のすべての変更に応答します。 CMR つまり診断データは CDR データとは別に有効にになります。 CMR のデータは CDR および Call Diagnostics の両方が有効でないかぎり生成されませんが、CDR データは CMR のデータがなくても生成されログに記録される場合があります。

CDR を有効にするには、次の手順を使用します。

  1. Cisco CallManager Administration を開きます。

  2. [Service] > [Service Parameters] の順に選択します。

  3. Cisco CallManager のインストールの IP アドレスを選択します。

  4. [Parameters] のリストから、[CDREnabled] を選択します。

  5. タイプを [boolean] として定義します。

  6. 真に対する [T] を選択します。

    /image/gif/paws/30266/serv_param_config2.gif

  7. 更新します。

    結果: コール詳細レコードがすぐにログの記録を開始します。

    注意 注意: 音声接続のトレースでは CDR ロギングがクラスタ内の各 Cisco CallManager のインストールで有効にされている必要があります。

    /image/gif/paws/30266/log_enable.gif

CDR

CDR は SDI トレースに含まれるの詳細情報を理解するのに役立つ基本情報を提供します。 基本 CDR は、発信者番号、着信者番号、発信元 IP アドレス、宛先 IP アドレス、通話時間などの情報を提供します。 CDR は電話問題のトラブルシューティングに使用できます。 たとえば、ユーザから特定の時間に発生するコールの問題の報告があった場合、指定された時間帯に発生した CDR を参照してそのコールおよびその他のコールに関する追加情報を調査できます。 CDR は通常は課金処理に使用されます。

Diagnostic CDR(別名 CMR)

Diagnostic CDR では、送信済み、受信済み、および失われたパケット数、およびジッターと遅延の数などの詳細なコール情報を提供します。 この詳細レベルによって、片通話などのいくつかの問題を説明できるようになります。 たとえば、片通話問題では 10,000 のパケット サイズで送信されていても、受信したサイズは 10 だけになってしまいます。

Windows NT および Internet Information Server(IIS)における CallManager の問題のトラブルシューティング

このセクションでは、Cisco CallManager と関連デバイスに発生する可能性のある一般的な問題のカテゴリについて説明します。 各問題のカテゴリでは、問題の特定に役立てるために使用する必要なのあるトラブルシューティング ツールを推奨します。 このドキュメントでは、潜在的な問題の一般的なカテゴリおよびこれらの問題のトラブルシューティング方法での推奨事項を示します。 これは問題と解決法の全リストを提供しません。 このドキュメントで説明するツールおよびユーティリティを使用して解決できない問題が発生した場合、Cisco Technical Assistance Center(TAC)に問い合わせてサポートを受けてください。 Cisco CallManager Administration Details が使用可能であり、さらに TAC に連絡する時点までに収集した任意の診断情報(トレースなど)が使用可能であることを確認します。

音声品質

音声品質問題は通話中の音声の消失や歪みなどです。 音が割れるなどの一般的な問題は、音声が断続的になる(言葉が断続的になるなど)、または音声の歪み(エコー)を発生したり、会話が水中でしゃべっていたりロボットがしゃべっているようになる影響を受ける奇妙な雑音を発生したりする原因になります。 片通話、つまり 2 人の会話で 1 人だけが何でも受信できる場合は実際には音声品質の問題ではありません。 これは、後でこのセクションで説明があります。

次のコンポーネントの一つ以上で音声の問題を起こす可能性があります。

  • ゲートウェイ

  • 電話

  • ネットワーク

適切に音声品質問題をトラブルシューティングするには、インフラストラクチャおよびすべてのデバイスでドロップや遅延を検討する必要があります。

音声の消失または歪み

発生する最も一般的な問題の 1 つが、音声の「中断」(通常、要領の得ない会話または単語や文の中の音節の損失として説明される)です。 これには、一般的な原因として次の 2 種類があります: パケット損失およびジッター。 パケット損失とは、音声パケットがドロップされたか、または使用するには到着が遅すぎたために、音声パケットが宛先に到着しないことを意味します。 ジッターは、パケット到着時間の変動を示します。 最適な状況では、1 台の電話機から別の電話機への VoIP パケットは 20 ミリ秒ごとに 1 パケットのレートで正しく到達します。 これは、パケットが A 地点から B 地点に到達するまでに要する時間は考慮されていないので、これは到着時間の一形態であることに注意が必要です。

実際のネットワークではさ多くの可変遅延の原因があります。 制御可能な原因もありますが、制御できないものもあります。 可変遅延は、パケット化された音声のネットワークで完全に除去できません。 電話機および他の音声対応デバイスのデジタル シグナル プロセッサ(DSP)は、可変遅延を予測して計画的に音声の一部をバッファに格納します。 音声パケットが宛先に到達し、従来のオーディオ ストリームを実行する準備が整った場合にだけこの「ジッター解除」が行われます(つまり、ユーザの耳で再生され、デジタル PCM ストリームを介して PSTN に送信されます)。 Cisco IP Phone 7960 は、1 秒以上の音声サンプルをバッファできます。 ジッター バッファには適応性がります。これは、パケットのバーストが受信された場合に、Cisco IP Phone 7960 ではジッターを制御するためにこれらのパケットを再生できることを意味します。 ネットワーク管理者は、(特にコールがワイドエリア ネットワークを通過する場合は)Quality of Service(QoS)およびその他の手段をあらかじめ適用して、パケット到着時間の間の変動を最小化する必要があります。

音声の消失または歪みの問題が発生している場合は、最初にその音声のパスを分離します。 コール音声ストリームのパスから個々のネットワーク デバイス(スイッチおよびルータ)を特定します。 音声は、2 つの電話機間の場合もあれば、電話機とゲートウェイ間の場合もあり、また、複数のレッグ(電話機からトランスコーディング デバイスへのレッグやトランスコーディング デバイスから別の電話機へのレッグ)が存在する可能性もあります。 問題が 2 つのサイト間だけで発生しているのか、特定のゲートウェイまたは特定のサブネットだけで発生しているのかなどを特定します。 これは、より注意深く調べる必要があるデバイスを絞り込むのに役立ちます。 次に、まだ無音圧縮(別名、音声アクティブ化検出または VAD)を無効にしていない場合は、多くの場合無音圧縮を無効にすることが最適です。 このメカニズムは、無音状態になったときに音声を送信しないことで帯域幅を節約しますが、その結果、単語の最初の部分ではっきりとわかる(そして許容できない)クリッピングが発生することがあります。 Cisco CallManager Administration で、[Service] > [Service Parameters] の下でこれを無効にすることができます。 ここで、サーバおよび Cisco CallManager サービスを選択します。 [SilenceSuppressionSystemWide] を「F」に設定します(代わりに [SilenceSuppressionWithGateways] を「F」に設定できますが、これは H.323 ゲートウェイまたは MGCP ゲートウェイには適用されません)。 判断がつかない場合は、それぞれに値 F を選択して、両方ともオフにします。

/image/gif/paws/30266/serv_param.gif

ネットワーク アナライザが使用できる場合、2 台の電話機の間のモニタ対象コールは、無音圧縮が無効の場合、1 秒間に 50 パケットです(つまり 20 ミリ秒ごとに 1 パケット)です。 適切なフィルタに掛けることで、パケットが失われたか、過度に遅延しているかを識別でき可能性があるはずです。

クリッピングの原因になるのは遅延そのものではなく、可変遅延だけです。 次の表は完全なトレースを示していますが、音声パケット(RTP ヘッダーを含んでいる)間の到着時間が 20 ms になっています。 低品質のコール(ジッターが多数存在するコールなど)では、到着時間に大きな差が出ます。

完全なトレース
パケット番号 時間: 絶対時間(ミリ秒) 時間: 差分(ミリ秒)
1 0
2 0.02 20
3 0.04 20
4 0.06 20
5 0.08 20

ネットワークのさまざまな箇所にパケット アナライザを設定すると、遅延が発生している場所を絞り込むために役立ちます。 アナライザが使用できない場合、別の方法が必要となります。 音声のパスにある各デバイスのインターフェイス統計情報を確認することが重要です。 音声品質の低いコールを追跡するもう一つのツールは診断コール詳細レコード(CDR)です。 CDR に関する詳細な情報については、「ツールとユーティリティ」および「コールの詳細な記録」の各項を参照してください。

ジッターおよび遅延の値はすべてのコールで取得できます(ただし、コールが終了した後でのみです)。 次は、Diagnostic CDR の例です(CallDetailRecordDiagnostic が実際のテーブルの名前です)。 送信済み、受信済み、および失われたパケット数、ジッター、および遅がすべて記録されます。 接続解除原因とその他の情報を取得できるように globalCallID 値が通常の CDR テーブルでコールを検索するために使用できます。 次の図は、開いた両方のテーブルを示しています。 Diagnostic CDR で、この情報をレポート可能な各デバイスが含まれることを認識します。 そうすれば、2 台の Cisco IP Phone の間で問題があれば、コールごとに 2 つのテーブル エントリを確認します。 たとえば、Cisco IOS ゲートウェイを経由するコールがある場合、ゲートウェイではなくこの Cisco IP Phone の診断情報だけを確認します。これは、この情報を使用して SQL データベースに通知するメカニズムがないためです。

ibutton.gif

i ボタンのヘルプ

Cisco IP Phone 7960 には、発生する可能性がある音声問題の診断ツールが、もう 1 つ用意されています。 アクティブ コールで、i ボタンを 2 回(すばやく)押して、統計を送受信するパケットと、平均および最大ジッター コンテナを含む情報スクリーンを電話機に表示できます。 この画面では、このジッターが受信した最後の 5 個のパケットの平均ではありません。 これは、最大ジッターが平均ジッターの最高水準マークだからです。

遅延とパケット損失の最も一般的な原因は、より高速なインターフェイスが低速なインターフェイスに送信するデバイスです。 たとえば、ルータに LAN に接続されている 100 Mb ファスト イーサネットのインターフェイスと、WAN に接続された低速なフレームリレーにある場合があります。 リモート サイトと通信する場合だけ低品質の問題が発生しする場合(もう 1 方向はすべてが良好に見えても、リモート サイトでのみ低い音声品質を報告する場合があります)、次はこの問題の最もよくある原因です。

  • 音声トラフィックの優先順位をデータ トラフィックより上に指定するようにルータが正しく設定されていません。

  • サポートする WAN に対するアクティブなコールが多すぎます(すなわち、発信するコール数を制限するコール アドミッション制御がありません)。

  • 物理ポートでエラーがあります。

  • WAN 自体に輻輳あります。

LAN で発生する最も一般的な問題は、ケーブル不良、インターフェイス不良、またはデバイスの設定不良(ポート速度やデュプレックスのミスマッチなど)が原因で発生する物理レベルのエラー(CRC エラーなど)です。 トラフィックが、ハブなどの共有メディア デバイスを通過していないことを確認します。 トラフィックが予想よりも低速のネットワーク パスを通過しているという状況が発生することもあります。 QoS が適切に設定されていれば、コール アドミッション制御がない可能性があります。 トポロジによりますが、これは Cisco CallManager Administration 設定内の [Locations] を使用して、またはゲートキーパーとして Cisco IOS ルータを使用して実行することが可能です。 いずれの場合も、WAN を介していくつのコールをサポートできるか常に認識しておく必要があります。 可能であれば、すでに説明したように無音圧縮を無効にして、2 つのサイト間でコールを送信してこれをテストします。 コールを保留またはミュートの状態にしないでください。これを行うと、パケットの送信が停止してしまうためです。 WAN 全体の最大コール数が設定されている場合は、すべてのコールが許容可能な品質になります。 さらにもう 1 つコールを発信するとファースト ビジー音が返ってくることを、テストして確認します。

クラックル ノイズ

別の「低品質」の症状は、クラックル ノイズです。これは、故障した電源または何らかの強い電気干渉が電話機のそばにあることによって発生することがあります。 電源を交換し、電話機を別の場所に移動してみてください。

負荷の確認

電話機およびゲートウェイを調べて、最新のソフトウェア ロードを使用していることを確認します。 不安がある場合は、最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートを、CCO(www.cisco.com の Cisco Connection Online)を確認してください。

Echo

プライマリ信号パスで送信される話し手の会話エネルギーが、遠端からの受信パスに乗った場合にエコー(別名「送話者エコー」)が発生します。 このとき話し手には、自分自身の声がエコー パスの合計遅延時間分だけ遅れて聞こえます。

/image/gif/paws/30266/voice.gif

上記の図では、John の音声(青)が反射して返されています。 反響は、従来の音声ネットワークでも発生する可能性がありますが、遅延が小さいため認識されません。 ユーザにとっては、エコーというよりも側音のように聞こえます。 VoIP ネットワークでは、パケット化および圧縮が常に十分な遅延の一因となるため、常にエコーが認識されます。 重要なことは、エコーの原因がアナログのコンポーネントおよび配線であることです。 たとえば、IP パケットはそのまま戻すことはできず、送信元から低い音声レベルで戻されます。 デジタル T1/E1 回線では、同じことはできません。 そのため 1 台の Cisco IP Phone から別の Cisco IP Phone へのコールでは、同じ問題はありません。 唯一の例外は、片方の通話者が音量を非常に高くしたスピーカフォンを使用している場合など、音声ループが作成されるいくつかの他の状況だけです。

エコーの問題をトラブルシューティングする場合、テストまたは検査される電話機はスピーカーフォンを使用していないことおよび適切なレベル(最大音声レベルの 50 パーセントから開始)に音量を設定するヘッドセットがあることを確認します。 ほとんどの場合、問題はデジタルまたはアナログ ゲートウェイ経由で PSTN に接続している場合に発生します。 Cisco IP Phone ユーザは、反射して自身の声が聞こえると不満を訴える可能性があります。 問題の実際真の原因はほとんどの場合発信元が遠端にいることですが、PSTN では常にほとんど何も変更することができません。 したがって、最初のステップは使用されているゲートウェイを見つけることです。 デジタル ゲートウェイが使用中の場合、より低い信号強度が低い反射エネルギーになる望みがあるので、送信方向(PSTN へ)の追加パディングに追加することが可能な場合があります。 また、反響音がさらに小さくなるように受信レベルを調節できます。 一度に少しずつ調整するように心がけることが非常に重要です。 信号を弱くしすぎると、両側で音声が聞こえなくなります。 または、通信事業者に問い合わせて、回線を確認するよう要求することもできます。 北米の一般的な T1/PRI 回線では、入力信号は -15 dB である必要があります。 信号レベルが高すぎる場合(-5 dB など)、エコーが発生する可能性があります。

エコーが発生したすべてのコールのログを保持してください。 問題の時間、送信元の電話番号、および着信番号がすべて記録されます。 ゲートウェイには 16 ms という固定値のエコー キャンセレーションが設定されています。 反射する音声の遅延がこれ以上長い場合は、エコー キャンセラが正し機能しません。 これはローカル コールでの問題ではなく、長距離コールでは、セントラル オフィスのネットワークに組み込まれた外部のエコー キャンセラを使用する必要があります。 これは、エコーが発生したコールの外部電話番号をメモしておくことが重要である理由の 1 つです。

負荷の確認

ゲートウェイおよび電話機のロードを確認する必要があります。 最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートを、CCO(www.cisco.com の Cisco Connection Online)を確認してください。

片通話または無音声

片通話は 1 人がコール中に相手の声が聞こえない場合に発生します。 これは、Cisco IOS ゲートウェイ、ファイアウォール、ルーティングやデフォルト ゲートウェイが正しく設定されていないことによる問題で、ほかの問題の中で発生する可能性があります。

通話中の片通話または無音声には多くの原因があります。 最も一般的な原因は、不適切に設定されたデバイスです。 たとえば、 Cisco CallManager は Cisco IP Phone のコール セットアップを処理します。 実際のオーディオ ストリームは 2 台の Cisco IP Phone 間で行われます(または Cisco IP Phone とゲートウェイ間)。 したがって、コールを発信する電話機に接続先電話機への IP ルートがない場合、Cisco CallManager が接続先電話機にシグナルを送る(ベルを鳴らす)ことは、完全に可能です。 これは電話のデフォルト ゲートウェイが正しく設定されていない(手動または Dynamic Host Configuration Protocol(DHCP)サーバ)場合に、よく発生します。

コールが常に片通話である場合、電話と同じサブネット上にあり、同じデフォルト ゲートウェイを持つ PC を使用して宛先の Cisco IP Phone にping を送信してみてください。 宛先の電話機と同じサブネット上にある PC (宛先の電話機と同じデフォルト ゲートウェイを持つ)を見つけて、発信元の電話機に ping を送信します。 これらのテストの両方が機能する必要があります。 また、ファイアウォールまたはパケット フィルタ(ルータのアクセス リストなど)は音声を 1 方向または両方向でブロックすることがあるので、音声トラフィックはこれらの影響を受ける場合もあります。 片通話が音声対応の Cisco IOS ゲートウェイのみを介して発生する場合は、設定を慎重に確認します。 IP ルーティングは有効にする必要があります(設定の最初の辺りに no ip routing が見当たらないことを確認するために設定を調べます)。 また、WAN 全体で帯域幅を節約するために RTP ヘッダー圧縮を使用している場合は、WAN 回線に接続する各ルータが転送する音声トラフィックで有効になっていることを確認します。 これは、RTP ヘッダーが一方の端で圧縮されるが WAN の反対側では復元できないという状況ではありません。 スニファは電話またはゲートウェイが実際にパケットを送信または受信しているかを家訓できるため、片通話の問題をトラブルシューティングする場合に非常に便利なツールなツールです。 Diagnostic CDR は、送受信パケットの詳細をログに記録するため(「音声の消失または歪み」を参照)、コールが片通話かどうかを決定するために役立ちます。 送受信されたパケットの詳細を表示するアクティブ コールの間に Cisco IP Phone 7960 の i ボタンを 2 回(すばやく)押します。

コールがミュートされている(電話機でミュート ボタンが押された)場合、パケットは送信されません。 [Hold] ボタンはオーディオ ストリームを停止するので、パケットはどちらの方向にも送信されません。 [Hold] ボタンが解除されると、すべてのパケット カウンタがリセットされます。 送信および受信カウンタが同じになるためには両方のデバイスで無音圧縮無効になっている必要があることに注意してください。 無音圧縮をシステム全体で無効にすることは、Cisco IOS ゲートウェイには影響を与えません。

MTP と片通話

コールでメディア ターミネーション ポイント(MTP)を使用している場合(H.323 バージョン 2 をサポートしない H.323 デバイスで保留や転送などの補足サービスをサポートするため)、割り当てられた MTP が正しく動作しているかどうかを確認します。 Cisco IOS ルータは、リリース 11.3(9)NA および 12.0(3)T 以降で H.323 バージョン 2 をサポートしています。 Cisco IOS release 12.0(7)T 以降では、オプションで H.323 Open/Close LogicalChannel がサポートされます。このため、ソフトウェア ベースの MTP は補足サービスに必要なくなります。

MTP デバイスは、会議ブリッジおよびトランスコーダと同様、2 つ以上のオーディオ ストリームをブリッジします。 MTP、会議ブリッジ、またはトランスコーダが正しく機能しない場合、片通話あるいは音声の消失が発生する場合があります。 MTP が問題を起こしているかどうかを確認するために MTP をシャット ダウンします。

電話のリセット

電話機は、次の 2 つの原因のうちの 1 つで電源の再投入またはリセットされます。

  • TCP が Cisco CallManager との接続に失敗する、または

  • 電話機のキープアライブ メッセージに対する確認応答の受信に失敗した。

電話機のリセットのトラブルシューティングの手順を次に示します。

  1. 電話機およびゲートウェイを調べて、最新のソフトウェア ロードを使用していることを確認します。

  2. 最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートを、CCO(www.cisco.com の Cisco Connection Online)を確認してください。

  3. 電話機のリセットのインスタンスがないかイベント ビューアーで確認します。 電話機のリセットは、次の図に示すとおり情報イベントと見なされます。

    /image/gif/paws/30266/event_prop.gif

  4. 電話機がリセットされた時間の前後でこのエラーおよび何らかのエラーが発生していないかどうかを調べます。

  5. SDI トレースを開始し、リセットされている電話機に共通する特徴を識別して、問題を切り分けます。 たとえば、これらの電話機がすべて同じサブネット、同じ VLAN などに配置されていないかどうかを確認します。 トレースを調べて、次の点を確認します。

    • リセットはコール中に発生しているのか、断続的に発生しているのか。

    • 電話機の類似モデル、 Cisco IP Phone 7960、Cisco IP Phone 30VIP などがないか。

  6. リセットが頻繁に発生している電話機でスニファ トレースを開始します。 リセット後に、TCP のリトライが発生していないかを判断するためにトレースを参照します。 発生している場合、ネットワークに問題があることを示しています。 トレースには、電話機が 7 日ごとにリセットされているなど、リセットにおける何らかの一貫性が示されることがあります。 これは、 DHCP リースの有効期限が 7日毎であることを示す場合があります(この値は、ユーザ設定可能で、 2 分毎などにすることもできます)。

切断されたコール

コールの切断は、コールが早く終了すると発生します。 特に問題が断続的であれば、コールの切断の可能性のある原因を判断するために CDR を使用できます。 コールの切断は電話やゲートウェイのリセットの結果(前述のセクションを参照)、または誤った PRI 設定やエラーなどの回線問題である可能性があります。

最初の手順は、この問題が 1 台の電話機または電話機のグループに特定されるかどうかを判断することです。 おそらく、影響をうけている電話機はすべて特定のサブネットまたはロケーションにあります。 次の手順は、イベント ビューアーで電話機またはゲートウェイのリセットを確認することです。

/image/gif/paws/30266/drop_call.gif

リセットされている電話機ごとに、警告メッセージおよびエラー メッセージが 1 つずつ表示されるはずです。 この場合、電話機が Cisco CallManager への TCP の接続をアクティブな状態に維持できないため Cisco CallManager が接続をリセットすることが問題であることがよくあります。 これは、電話機の電源が切られたか、またはネットワークに問題がある可能性があります。 問題が断続的に発生する場合、電話機の登録を記録するために Microsoft パフォーマンスを使用すると役立つ場合があります。

/image/gif/paws/30266/drop_call2.gif

問題が Cisco Access DT-24+ などの特定のゲートウェイのみを介して発生しているように見える場合は、最善のアクションはトレースを有効にして CDR を確認することです。 CDR ファイルには、問題の原因特定に役立つ可能性のある Cause Of Termination(CoT)が含まれています。

drop_call3.gif

接続解除の原因値(どちら側でコールが切断されたかによって、origCause_value および destCause_value)は、ISDN スイッチ タイプ、コード、および値で見つかる可能性のある Q.931 接続解除原因コード(10 進数)にマップされます。 上記の例では、原因 16 は正常なコール クリアもクリアを示します。 コールがゲートウェイ から出て PSTN に行く場合、どちら側でコールが接続解除されているかを判断するために CDR を使用できます。 Cisco CallManager のトレースを有効にすると、同じ情報がたくさん取得される可能性があります。 ネットワークがまだ実稼働していない場合は、このトレース ツールは最後の手段としてのみ使用します。

負荷の確認

どの問題の場合も、電話機とゲートウェイの負荷を確認し、最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートを、CCO(www.cisco.com の Cisco Connection Online)を確認してください。

Cisco CallManager の機能に関する問題

問題が、Cisco CallManager と連動して使用される会議ブリッジまたはメディア ターミネーション ポイントなどの機能で発生する場合があります。 これらの機能に関する問題の一部は、設定のエラーまたはリソースの不足により発生します。 たとえば、アドホック会議のリソースの指定数を超過するとユーザは電話会議に参加できない場合があります。 この結果、ユーザが会議機能を開始しようとしたときにコールが切断されます。 これは、実際に使用できる会議リソースの数の問題がある場合に、Cisco CallManager の機能上の問題となる場合があります。 会議リソースが要求され使用できなかった回数は、Microsoft パフォーマンスにログが記録されるカウンタの 1 つです。 使用できる会議リソースがあっても会議サービスが停止していると、同じことが行われます。

コーデック/リージョン: コーデックの不一致

ユーザがオフフックしたときにリオーダー音を受信する場合は、結果としてリージョン間のコーデックの不一致になる可能性があります。 コールの両端で 1 つ以上の共通コーデック(G.711 など)がサポートされていることを確認します。 サポートされていない場合は、トランスコーダを使用する必要があります。

リージョンは、他の個々のリージョンと併用可能なサポート コーデックの範囲を示します。 すべてのデバイスがリージョンに属します。

Cisco IOS ルータでのコーデックのネゴシエーションはサポートされていません。

Region1<->Region2 = G.711 は、Region1 のデバイスと Region2 のデバイス間のコールで、G.711 または G.711 と同じかそれよりも少ない帯域幅を必要とする他のサポート コーデック(G.711、G.729、G.723 などのサポート コーデック)を使用できることを意味します。

各デバイスで次のコーデックがサポートされます。

  • Cisco IP Phone 7960 G.711A law/?関連法規、G.729AnnexB

  • Cisco IP Phone SP12 シリーズおよび VIP 30 G.711A law/?関連法規、G.723.1

  • Cisco アクセスゲートウェイ DE30 および DT-24+ G.711A law/?関連法規、G.723.1

ロケーション

番号に電話をかけた後でリオーダー音を受信する場合、コールのエンド デバイスのうちの 1 台のロケーションの Cisco CallManager 帯域幅割り当てを超過(24k 未満)したためである可能性があります。 Cisco CallManager では、コールを行う前に各デバイスの 24k の使用可能な帯域幅を確認します。 使用可能な帯域幅が 24k 未満の場合、Cisco CallManager でコールが設定されず、ユーザにはリオーダー音が聞こえます。

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 
(-1 implies infinite bw available)

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallState tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=,
 CalledParty=5005, tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98 

コールが確立されると、Cisco CallManager はそのコールに使用されているコーデックをもとにロケーションから帯域幅を差し引きます。 コールが G.711 を使用する場合、Cisco CallManager は 80k を差し引きます。 コールが G.723 を使用する場合、Cisco CallManager は 24k を差し引きます。 コールが G729 を使用する場合、Cisco CallManager は 24k を差し引きます。

会議ブリッジ

「No Conference Bridge available」の問題のトラブルシューティングに役立てるために次の情報を使用します。 これは、ソフトウェアまたはハードウェアの問題である可能性があります。

最初に、Cisco CallManager に登録されている使用可能な会議ブリッジ リソース(ソフトウェアまたはハードウェア)があるかどうかを調べます。 そのためには、「Unicast AvailableConferences」の数を確認するために Microsoft パフォーマンスを使用できます。

Cisco IP Voice Media Streaming アプリケーションは、会議ブリッジ機能を実行します。 次のトレースに示すように、Cisco IP Voice Media Streaming の 1 つのソフトウェア インストレーションで、16 の Unicast Available Conferences(3 人/会議)がサポートされます。

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB_kirribilli - Registered - ConfBridges= 16,
 Streams= 48, tcpHandle=4f12738

10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??%? - DeviceType= 50, ResourcesAvailable= 16, 
deviceTblIndex= 0 

次のトレースに示すように、1 つの E1 ポート(WS-X6608-E1 カードには 8 個の E1 ポートがあります)によって、5 つの Unicast Available Conferences(最大会議サイズ = 6)が提供されます。

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, 
tcpHandle=4f19d64

11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??% - DeviceType= 51, ResourcesAvailable= 5,
 deviceTblIndex= 0 

Cisco Catalyst 6000 8 Port Voice T1/E1 and Services Module の次のハードウェア トレースは、カードの E1 ポート 4/1 が Cisco CallManager に会議ブリッジとして登録されたことを示しています。

greece-sup (enable) sh port 4/1

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/1 enabled 1 full - Conf Bridge


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/1 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/1 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/1 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/1 disabled disabled

第 2 に、会議に設定されているユーザの最大数(アドホックまたはミートミー)を確認し、この数を超えたために問題が発生したかどうかを判断します。

問題のトランスコーディング

Cisco Catalyst 6000 8 Port Voice T1/E1 にトランスコーダをインストールしていて、それが期待通りに機能していない(つまり共通のコーデックがない 2 人のユーザ間でコールを行えない)場合、およびサービス モジュールにハードウェア たら、および期待どおりに働かなかったら、Cisco CallManager に登録されている使用可能なトランスコーダ リソースがあるかどうかを確認します(これはハードウェアである必要があります)。 使用できる「MediaTermPointsAvailable」の数を確認するために Microsoft パフォーマンスを使用します。

次のトレースに示すように、1 つの E1 ポート(WS-X6608-E1 カードには 8 個の E1 ポートがあります)によって、16 コールのトランスコーダ/MTP リソースが提供されます。

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

Cisco Catalyst 6000 8 Port Voice T1/E1 and Services Module の次のハードウェア トレースは、カードの E1 ポート 4/2 が Cisco CallManager に MTP/トランスコーダとして登録されたことを示しています。

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

同じ E1 ポートは会議ブリッジとトランスコーダ/MTP の両方には設定できません

同じコーデックをサポートしない、低ビット レート コード(G.729 や G.723 など)を使用している 2 つのデバイス間で通話するには、トランスコーダ リソースが必要です。 次の図を検討してください。

/image/gif/paws/30266/ccm_ill.gif

Cisco CallManager で、Region1 と Region2 の間のコーデックが G.729 に設定されているとします。 次のシナリオが可能です。

  • 電話機 A の発信者がコールを開始した場合、Cisco CallManager が Cisco IP Phone 7960 であることを認識し、G.729 のサポートが発生します。 番号が収集されたあと、Cisco CallManager は、コールの宛先が Region2 にいるユーザ D であることを判別します。 宛先デバイスも G.729 をサポートしているため、コールがセットアップされ、音声は電話機 A と電話機 D の間を直接流れます。

  • Cisco IP Phone 12SP+ を使用する電話 B の発信者が電話 D へのコールを開始する場合、このときは Cisco CallManager は、発信元電話機が G.723 または G.711 だけをサポートしていることを認識します。 Cisco CallManager は、音声が電話機 B とトランスコーダの間は G.711 として流れ、トランスコーダと電話機 D の間は G.729 として流れるように、変換リソースを割り当てる必要があります。 トランスコーダを使用できない場合、電話機 D は鳴りますが、コールに応答するとすぐにコールが接続解除されます。

  • 電話機 B のユーザが電話機 F(Cisco IP Phone 12SP+)にコールした場合、リージョン間で使用するコーデックとして G.729 が設定されていても、2 つの電話機は実際には G.723 を使用します。 G.723 が使用されるのは、両方のエンドポイントがそれをサポートしており、使用する帯域幅が G.729 よりも少ないためです。

  • Cisco uOne ボイスメール システム(G.711 のみをサポート)または G.711 用に設定された Cisco IOS ルータがリージョン 1 に追加された場合、リージョン 2 からの呼び出しがあった場合トランスコーディング デバイスが使用される必要があります。 どちらも使用できない場合、コールは失敗します。

MTP リソースの問題

コールが確立されたが補足サービスが H323v2 をサポートしない H.323 デバイスで使用できない場合、MTP リソースの問題が原因である可能性があります。 最初に Cisco CallManager に登録されている使用可能な MTP リソース(ソフトウェアまたはハードウェア)があるかどうかは判断します。 これは、「MediaTermPointsAvailable」の数を確認するために Microsoft パフォーマンスを使用して実施できます。

1 つの MTP ソフトウェア アプリケーションは次のトレースに示すように 24 コール(H.323v2 をサポートしない H.323 デバイスで使用する補足サービスをサポートする MTP を使用)をサポートしています。

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP_kirribilli. - Registered - Supports 24 calls

次のトレースに示すように、1 つの E1 ポート(WS-X6608-E1 カードには 8 個の E1 ポートがあります)によって、16 コールの MTP リソースが提供されます。

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

Cisco Catalyst 6000 8 Port Voice T1/E1 and Services Module からの次のハードウェア トレースは、カードの E1 ポート 4/2 が Cisco Unified Communications Manager に MTP/トランスコーダとして登録されたことを示しています。

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

2 番目に、Cisco CallManager Administration の [Gateway Configuration] 画面で [Media Termination Point Required] チェックボックスが選択されますかどうかを確認します。

3 番目に、Cisco CallManager が必要な数の MTP デバイスに割り当てられていることを確認します。

SDI ファイルから:

15:22:23.848 Cisco CallManager|MediaManager(40) started

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder 
  Enabled

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), 
  party2(16777358), proxies=1, connections=2, current proxies=0

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy 
  connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating 
  MTP(ci=16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - start 2 connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777357) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777358) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - 
  CI=16777359 count=1

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource 
  - CI=16777359 count=2

ダイヤル プラン

ダイヤル プランは、特定の数字の列が収集されるときにどのデバイスが(電話、ゲートウェイなど)コールを送信しているのかを Cisco CallManager に通知する番号(および番号のグループ)のリストです。 これは、ルータのスタティック ルーティング テーブルに似ています。 ダイヤル プランの潜在的な問題をトラブルシューティングする前に、ダイヤル プランの概念、基本的なコール ルーティング、およびプランニングが慎重に考慮され、適切に設定されていることを確認してください。 たいていの場合、プランニングと設定に問題があります。

ダイヤル プランの問題をトラブルシューティングする場合は次の質問を考慮してください。

  • コールを発信する電話番号(DN)は何ですか。

  • この DN のコーリング サーチ スペースは何ですか。

  • 該当する場合、DN が関連付けられているデバイス(Cisco IP Phone など)のコーリング サーチ スペースは何ですか。 適切なデバイスを識別していることを確認します。 複数ライン アピアランスがサポートされ、1 つの DN を複数のデバイスに設定することも可能です。 デバイスのコーリング サーチ スペースに注意します。 コールが Cisco IP Phone から発信される場合、特定の回線(DN)とその回線が関連付けられているデバイスにそれぞれコーリング サーチ スペースがあります。 これらはコールが発信されると統合されます。 例として、回線インスタンス 1000 に AccessLevelX のコーリング サーチ スペースがあり、内線 1000 が設定されている Cisco IP Phone にはコーリング サーチ スペースとして AccessLevelY があるとします。 したがって、コールをこのライン アピアランスから行った場合、Cisco CallManager はコーリング サーチ スペース AccessLevelX と AccessLevelY に含まれているパーティションを検索します。

  • コーリング サーチ スペースでどのパーティションが関連付けられていますか。

  • コールを受信する必要のある(または受信しない)デバイスのパーティションは何ですか。

  • かけられている電話番号は何ですか。 発信者が第 2 発信音を聞いたかどうか、またいつ聞いたのかを、どの段階でもメモしておきます。 また、すべての番号を入力した後に発信者は何を(リオーダー、ファースト ビジー)聞きましたか。 発信者が何かが聞こえると予測する前にプログレス トーンを聞きましたか。 発信者が番号間タイマーの時間が経過するまで待機する場合があるため、発信者が最後の番号を入力したあと少なくとも 10 秒間待機してください。

  • Cisco CallManager Administration で Route Plan Report を生成します。 これは、このコールのコーリング サーチ スペースにあるパーティションのすべてのルート パターンを確認するために使用します。

  • 必要に応じて、ルート パターンまたはルート フィルタを追加または変更します。

  • コールの送信先ルート パターンを検出できる場合は、パターンが指すルート リストまたはゲートウェイをメモします。

  • ルート リストの場合は、リストに含まれているルート グループとルート グループに含まれているゲートウェイを確認します。

  • 該当するデバイスが Cisco CallManager に登録されていることを確認します。

  • Cisco CallManager へのアクセスがない場合は、show tech を実行して、この情報をキャプチャして確認します。

  • @ 記号に注意してください。 これは、多くの異なるものを含むように展開できるマクロです。 これは、多くの場合、フィルタリング オプションと組み合わせて使用されます。

  • デバイスがパーティションに含まれていない場合は、Null パーティションまたはデフォルト パーティションに含まれていると言われます。 この場合、すべてのユーザがそのデバイスにコールできます。 空のパーティションは常に最後に検索されます。

  • 9.@ パターンに一致する外線番号をダイヤルし、コールが成功するまで 10 秒かかる場合は、フィルタリング オプションを確認します。 9.@ パターン、つまり 7 桁の番号をダイヤルしたとき、(デフォルトで)10 秒間待ちます。 LOCAL-AREA-CODE DOES-NOT- EXIST と END-OF-DIALING DOES-NOT-EXIST というルート フィルタをパターンに適用する必要があります。

パーティション

ルート パーティションは Cisco CallManager ソフトウェアのエラー処理の機能を継承します。 つまり、情報とエラー メッセージをログに記録するためにコンソールおよび SDI ファイル トレースが提供されます。 これらのメッセージは、トレースの番号分析コンポーネントの一部となります。 次のトレースでも、パーティションとコーリング サーチ スペースの設定、および各パーティションにどのデバイスがあるのか、さらに関連するコーリング サーチ スペースについて理解しておくことは問題の判定に重要です。

次のトレースは、デバイスのコーリング サーチ スペースにあるダイヤルされた番号の例です。 SDI トレースの詳細な説明については、このマニュアルに記載されているケース スタディを参照してください。

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028|

  08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

トレースの番号分析コンポーネント(上記)では、「pss」(パーティション サーチ スペース。コーリング サーチ スペースとも呼ばれる)がコールを発信しているデバイスに対してリストされています。 次の例では、「RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP」がこのデバイスがコールに許可しているパーティションであることが確認できます。

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 5 tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

  08:38:55.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

  08:38:56.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

  08:38:56.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 3 tcpHandle=0x6b88028

  08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

  08:38:56.515 Cisco CallManager|Digit analysis: analysis results

  08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

上記の例では、完全一致が見つかり、それによってコールがルーティングされるまで、「PotentialMatchesExist」がダイヤルされた番号の番号分析の結果であることに注意することが重要です。

次は、ダイヤルした番号(1001)がデバイスのコーリング サーチ スペースにない場合のトレースを示しています。 再度言いますが、最初の数字をダイヤルするまでのみ番号分析ルーチンで一致が見つかる可能性があることに注意することが重要です。 桁「1」に関連付けられているルート パターンは、デバイスのコーリング サーチ スペース「RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP」にないパーティションにあります。 したがって、電話機にリオーダー音が送信されました。

08:38:58.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

  08:38:58.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 1 tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

  08:38:59.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist

  08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone 
  tcpHandle=0x6b88028

ルート パーティションは、パーティション名をシステム内のすべての電話番号に関連付けることによって機能します。 電話番号に発信できるのは、発信側デバイスに含まれているパーティションが、デバイスのパーティション サーチ スペース内でコールの発信が許可されているパーティションのリストある場合だけです。 これにより、ルーティングを強力に制御することが可能です。

コールの発信中に、番号分析では、ダイヤルされたアドレスをパーティション サーチ スペースで指定されているパーティション内でだけ解決しようとします。 各パーティション名は、グローバルなダイヤル可能アドレスの個別のサブセットで構成されています。 番号分析では、ダイヤルされた一連の番号に最もよく一致するパターンを、リストされた各パーティションから抽出します。 次に、一致したパターンの中から番号分析がベストマッチを選択します。 2 パターンが同等にダイヤルされた番号の順番に一致する場合、番号分析ではパーティション サーチ スペースの最初にリストされているパーティションに関連付けられているパターンを選択します(詳細については、最近接一致ルーティングに関する文書を参照してください)。

セキュリティ

Cisco CallManager では、ユーザのセキュアなダイヤル プランを作成するように設定できます。 これは、パーティションとコーリング サーチ スペースを使用して実行できます。さらに、Area Code などのルート パターン内の「@」マクロ(北米番号計画を意味する)のセクションに基づいたより一般的なフィルタリングも使用できます。 パーティションとコーリング サーチ スペースはセキュリティに不可欠であり、特にマルチテナント環境や個々のユーザ レベルの作成に役立ちます。 コーリング サーチ スペースまたはパーティション概念のサブセットであるフィルタリングによって、セキュリティ プランをさらに詳細に設定できます。

これは、前出の「ダイヤル プラン」の項の拡張です。 フィルタリングの問題を修復する場合には SDI トレースを実行することはお勧めしません。 十分な情報がない上に、追加の問題を引き起すする可能性が大きすぎます。

Cisco CallManager の show tech を実行してください。 次の情報は、[Route Filter] セクションに表示されます。

Show-tech
名前 dialPlanWizardG 条件文
CiscoDallasInte 1 (INTERNATIONAL-
CiscoRTPTollByP 1 (AREA-CODE == 9
CiscoRTPLongDis 1 (AREA-CODE EXIS
CiscoDallasToll 1 (AREA-CODE == 9
CiscoDallas911R 1 (SERVICE == 911
CiscoRTPLocal7D 1 (AREA-CODE DOES
CiscoDallasLong 1 (AREA-CODE EXIS
CiscoRTP911RF 1 (SERVICE == 911
CiscoRTPInterna 1 (INTERNATIONAL-
CiscoDallasLoca 1 (LOCAL-AREA-COD

残念ながら、この表示は不完全です。 ただし、システムのすべてのルート フィルタのリストを示しています。 showコマンドでは、どのフィルタがどのルート パターンと関連付けられているかを表示することはできません。 ダイヤル プランを理解するもう一つの方法は、[Route Plan Report] ページに移動することです。 次は、一番右側にあるファイルを表示するオプション「View In File」です。

file_dl.gif

出力は、Microsoft Excel や類似のアプリケーションで表示される一般的なカンマ区切りのファイルになります。

Show-tech ファイル出力
パターン/DN Partition パターンの使い方 Device Name デバイスの説明
1000 デバイス SEP003094C2635E Telecaster
1010   デバイス SEP003094C2635E Telecaster
1111   デバイス SEP00308062CDF1 SEP00308062CDF1
1211   デバイス SEP00308062CDF1 SEP00308062CDF1
2999   デバイス SAA0010EB007FFE SAA0010EB007FFE
4444   デバイス SEP003094C26302 ゲスト
4500   会議  
9.@ CiscoRTPLocalPT ルート CiscoRTPLocalRL
9.@ CiscoDallasLocalPT ルート CiscoDallasLocalRL
9.@ CiscoRTPIntlPT ルート CiscoRTPIntlRL
9.@ CiscoDallasLongDistPT ルート CiscoDallasLongDistRL
9.@ CiscoRTP911PT ルート CiscoRTP911RL
9.@ CiscoRTPLongDistPT ルート CiscoRTPLongDistRL
9.@ CiscoTollByPassToDallasPT ルート CiscoTollByPassToDallasRL
9.@ CiscoDallasIntlPT ルート CiscoDallasIntlRL
9.@ CiscoDallas911PT ルート CiscoDallas911RL
9.@ CiscoTollByPassToRTPPT ルート CiscoTollByPassToRTPRL

これは、ルート パターンと対応するのパーティションを示しています。 これは、電話番号のルート フィルタまたはコーリング サーチ スペースは示していません。 さらに多くの情報が、実際の Route Plan Report で使用できます。 Cisco TAC に連絡する必要がある場合は、電子メールでこのページを送信する必要があります(Cisco CallManager にアクセスできない場合です)。

次は、ルート パターン、パーティション、およびルート リスト/ルート グループ/ゲートウェイのレイアウトです。

route_plan_rpt.gif

遅いサーバ応答

サーバからの応答が遅い場合は、スイッチのデュプレックスが Cisco CallManager サーバのデュプレックスに一致しない場合に発生している可能性があります。 最適なパフォーマンスのために、スイッチとサーバの両方で「100/Full」に設定します。ここでは、スイッチまたはサーバのどちらにも「Auto」を使用することは推奨しません。 変更を実際に機能させるために Cisco CallManager サーバを再起動する必要があります。

ゲートウェイを経由したトーンの再配置

ゲートウェイ経由でコールを発信するユーザは、制限されたコールを発信しようとした場合、またはブロックされている番号をコールしようとした場合に、リオーダー 音を受信することがあります。 リオーダー音は、ダイヤルされた番号がアウト オブ サービスになっている場合や、PSTN に機器またはサービスの問題がある場合に発生することがあります。 リオーダー音を与えるデバイスが登録されていることを確認してください。 また、ダイヤル プラン設定を調べて、コールが正しくルーティングされることを確認してください。

ゲートウェイを介したリオーダー音のトラブルシューティングの手順は次のとおりです。

  1. ゲートウェイを調べて、最新のソフトウェア ロードを使用していることを確認します。

  2. 最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートを、CCO(www.cisco.com の Cisco Connection Online)を確認してください。

  3. SDI トレースを開始して、問題を再現します。 リオーダー音は、Cisco CallManager で許容可能なコール数が制限されている、ロケーションベースのアドミッション制御またはゲートキーパーベースのアドミッション制御に関わる設定の問題によって発生する場合があります。 SDI トレースでコールを特定し、そのコールがルート パターンやコーリング サーチ スペース、またはその他の設定値によって意図的にブロックされたのかどうかを確認します。

  4. リオーダー音は、コールが PSTN 経由で発信されている場合にも発生する可能性があります。 Q.931 接続解除メッセージの SDI トレースを確認します。 Q.931 接続解除メッセージが見つかった場合、接続解除の原因は相手側にあるため、こちら側では修正できないことを意味します。

ゲートウェイ登録に関する問題

Cisco CallManager のゲートウェイで発生する最も一般的な問題の 1 つが登録の問題です。 登録は、さまざまな理由で失敗する可能性があります。

ここでは、2 つの類似しているけれども同一ではないゲートウェイ カテゴリについて扱います。 Analog Access AS-X と AT-X および Digital Access DT-24+ と DE-30+ は 1 つのカテゴリに属します。 これらのゲートウェイは、ネットワーク管理プロセッサ(NMP)に直接接続されていないスタンドアロン装置です。 2 つめのカテゴリには、Analog Access WS-X6624 および Digital Access WS-X6608 が含まれます。 これらのゲートウェイは、Catalyst 6000 シャーシにインストールされているブレードで、制御およびステータス管理のために NMP に直接接続できます。

次の例では、説明するメッセージは、太字のテキストによって識別されます。 これにより、確認が容易になります。 実際の出力では、テキストは太字ではありません。 この例は、WS-X6624 からのものです。

最初に確認するのは、ゲートウェイが稼働中であることです。 すべてのゲートウェイに、ゲートウェイ ソフトウェアが正常に実行しているときには 1 秒間隔で点滅する「ハートビート」LED があります。 この LED が点滅していない場合、または非常に高速に点滅している場合は、ゲートウェイ ソフトウェアは実行していません。 結果として、通常、ゲートウェイは自動的にリセットされます。 また、2 ~ 3 分経っても登録処理が完了しない場合にゲートウェイがそれ自体でリセットするのは、正常な動作です。 このため、デバイスがリセット中にハートビート LED を見ることがあります。 通常の点滅パターンが 10 ~ 15 秒以内に表示されない場合、ゲートウェイで重大な障害が発生しています。 AS-X ゲートウェイまたは AT-X ゲートウェイでは、ハートビート LED は前面パネルの右端の緑色の LED で表示されます。 DT-24+ ゲートウェイまたは DE-30+ ゲートウェイでは、これはカードの左上端の赤い LED です。 Analog Access WS-X6624 では、これはブレード内部(前面パネルからは見えない)の前面に近いカードの右端の緑色の LED です。 最後に、Digital Access WS-X6608 では、ブレードの 8 つのスパンのそれぞれに個別のハートビート LED があります。 カードの後ろに向かって約 3 分の 2 のところまでカード全体に(前面パネルから見えない) 8 個の赤い LED があります。

2 番目に確認するのは、ゲートウェイが IP アドレスを受信したことです。 スタンドアロン ゲートウェイは、DHCP または BOOTP を介して自身の IP アドレスを受信する必要があります。 Catalyst ゲートウェイは、DHCP や BOOTP を使用して、または NMP による手動設定で、自身の IP アドレスを受信することがあります。 DHCP サーバにアクセスできる場合、スタンドアロン ゲートウェイを確認する最善の方法は、デバイスに未処理の IP アドレス リースがないかどうかを確認することです。 ゲートウェイがサーバに表示される場合、これは良い指標になりますが、決定的ではありません。 リースを DHCP サーバで削除し、ゲートウェイをリセットします。 数分以内にリースとともにゲートウェイがサーバに表示された場合、これでこの領域ではすべてが正常に機能しています。 再表示されない場合は、ゲートウェイが DHCP サーバに接続できない(ルータの設定に誤りがあり、DHCP ブロードキャストが転送されていない、 サーバが稼働していないなど)、または肯定応答を取得できない(IP アドレス プールが枯渇しているなど)状態です。 このような内容を確認しても答えが得られない場合は、スニファ トレースを使用して問題を特定します。

Catalyst 6000 ゲートウェイの場合、NMP がゲートウェイと通信できることを確認する必要があります。 これを確認するには、NMP から内部 IP アドレスに ping します。 IP アドレスは、次の形式です。

127.1.module.port

したがって、この例では次のように実行します。

Console (enable) ping 127.1.7.1

127.1.7.1 is alive

ping が正常に機能した場合、show port コマンドで IP アドレス情報を表示します。 IP アドレス情報および TFTP IP アドレスが正しいことを確認します。 ゲートウェイが有効な DHCP 情報の取得に失敗している場合は、問題の特定に tracy ユーティリティ(Cisco TAC から提供可能)を使用できます。 Cat6000 CLI から次のコマンドを発行します。

tracy_start mod port

この例では、WS-X6624 はモジュール 7 で、860 プロセッサが 1 つしかないため、これがポート 1 になります。 ここで発行したコマンドは tracy_start 7 1 です。

次は、ゲートウェイ ボード自体の 860 コンソール ポートから実際に出力されたものです。 ただし、この tracy コマンドの出力は 860 のコンソール ポートのリモート コピーにすぎません。

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT

上記のタイムアウト メッセージがスクロールし続ける場合は、DHCP サーバへの接続で問題が発生しています。 Catalyst 6000 ゲートウェイ ポートが正しい VLAN 内にあることを確認します。

この情報は、show-++ port コマンドの前後にあります。 DHCP サーバが Catalyst 6000 ゲートウェイと同じ VLAN に配置されていない場合、DHCP 要求を DHCP サーバに転送するように適切な IP ヘルパー アドレスが設定されていることを確認します。 ゲートウェイで VLAN 番号を変更した後、リセットするまで INIT 状態のまま動作しなくなるになる場合があります。 この場合は、ゲートウェイをリセットしてみることができます。 860 がリセットされるたびに、tracy のセッションが失われます。 そのため、現在のセッションを終了して、次のコマンドを発行して新しいセッションを再確立する必要があります。

tracy_close mod port

tracy_start mod port

これらすべてを確認し、まだ DHCPState = INIT のメッセージが表示される場合は、DHCP サーバが正しく動作しているかどうかを確認します。 正しく動作している場合は、スニファ トレースを開始して、要求が送信されているかどうか、およびサーバが応答しているかどうかを確認します。

DHCP が正しく動作している場合は、tracy デバッグ ユーティリティを使用できるようにする IP アドレスがゲートウェイに割り当てられます。 このユーティリティは、Catalyst ゲートウェイ用に設定された NMP コマンドの組み込み機能で、Windows 98/NT/2000 で実行するヘルパー アプリケーションとしてスタンドアロン ゲートウェイに使用できます。 ヘルパー アプリケーションとして tracy ユーティリティを使用するには、割り当てられている IP アドレスを使用してゲートウェイに接続(「Connect」)する必要があります。 この tracy アプリケーションはすべてのゲートウェイで動作し、ゲートウェイごとに個別のトレース ウィンドウを提供して(一度に最大 8 つのトレースが可能)、指定されたファイルにトレースを直接記録できるようにします。

次の手順では、TFTP サーバの IP アドレスがゲートウェイに正しく提供されていることを確認します。 これは、オプション 66(名前または IP アドレスによって)、オプション 150(IP アドレスのみ)、または si_addr(IP アドレスのみ)のいずれで DHCP によって通常は提供されます。 サーバに複数のオプションが設定されている場合、si_addr はオプション 150 に優先し、オプション 150 はオプション 66 に優先します。 オプション 66 で TFTP サーバの DNS_NAME が提供される場合、DNS サーバの IP アドレスは DHCP で指定されている必要があり、さらにオプション 66 で入力された名前は正しい TFTP サーバの IP アドレスに解決される必要があります。 Catalyst ゲートウェイは DHCP をディセーブルにするように NMP で設定できます。その場合、NMP オペレータはコンソールで、TFTP サーバ アドレスなどの設定パラメータをすべて手動で入力する必要があります。

また、ゲートウェイは常に DNS を使用して名前「CiscoCM1」を解決しようとします。 解決に成功した場合、CiscoCM1 の IP アドレスは、NMP で DHCP がディセーブルになっていても、DHCP サーバまたは NMP が TFTP サーバ アドレスとして示すすべてに優先します。

tracy ユーティリティを使用すると、ゲートウェイにある現在の TFTP サーバの IP アドレスを確認できます。 次のコマンドを入力して、設定タスク番号を取得します。

TaskID: 0

Cmd: show tl

「config」または「CFG」の行を探し、taskID として対応する番号を次の行に使用します。 たとえば次は、Digital Access WS-X6624 ゲートウェイで、DHCP 情報をダンプするコマンドです。

TaskID: 6

Cmd: show dhcp

これで、TFTP サーバ IP アドレスが明示されます。 この IP アドレスが正しくない場合は、表示された DHCP オプションおよび他の情報が正しいかどうかを確認します。

それでも TFTP アドレスが正しい場合は、次の手順は、ゲートウェイがコンフィギュレーション ファイルを TFTP サーバから取得していることを確認します。 tracy 出力に次の項があれば、TFTP サーバは正常に機能していないか、あるいはゲートウェイが Cisco CallManager 上で構成されていない可能性があります。

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server

    00:09:18.620 (CFG) TFTP 
    Error: Timeout Awaiting Server Response for .cnf File!

もしコンフィギュレーション ファイルを受信していないのであれば、ゲートウェイは TFTP サーバと同じ IP アドレスへの接続を試みます。 ゲートウェイが冗長な Cisco CallManager のリストの受信を必要とするようなクラスタ環境でない限り、これは問題ではありません。 カードが TFTP 情報を正常に受信しない場合は、Cisco CallManager の TFTP サーバを調べて、これが正常に機能していることを確認します。 また、同様に Cisco CallManager で TFTP トレースを調べます。

別のよくある問題は、Cisco CallManager でゲートウェイが正しく設定されていないケースです。 典型的なエラーとしては、ゲートウェイに不正な MAC アドレスが入力されている場合があります。 この場合、Catalyst 6000 ゲートウェイでは、次のメッセージが 2 分ごとに NMP コンソールに表示されます。

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously

これは Cisco CallManager データベース上にゲートウェイがない場合の tracy 出力の例です。

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM

他に発生する可能性がある登録の問題としては、ロード情報が正しくない場合、またはロード ファイルが破損している場合があります。 TFTP サーバが機能していない場合にも、問題が発生します。 この場合は、tracy コマンドで、TFTP サーバによってファイルが検出されないと報告されたことが、明確に示されます。

00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse

この例では、正しいロード名が A0020300 にも関わらず、ゲートウェイがアプリケーション ロード A0021300 を要求したことがわかります。 Catalyst 6000 ゲートウェイでは、新しいアプリケーション ロードで対応する DSP ロードの取得も必要になる場合に、同じ問題が発生する可能性があります。 新しい DSP ロードが見つからない場合、同様のメッセージが表示されます。

次は、Analog Access WS-X6224 で間違ったアプリケーション ロードを取得する設定がされている場合の出力です。 外観は、Cisco CallManager に設定されていないゲートウェイと似ています。

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse

ここで異なるのは、ゲートウェイが LoadResponse 段階のままになり、最終的にはタイムアウトになることです。 この問題は、Cisco CallManager Administration の [Device Defaults] 領域内でファイル名を修正して解決できます。

ゲートキーパーの諸問題

ゲートウェイとゲートキーパー間のすべてのトラブルシューティングを開始する前に、ネットワーク内に IP 接続があることを確認します。 IP 接続があることを確認するには、この項の情報を使用してゲートウェイをトラブルシューティングします。

クラスタ間トランクのみ

Cisco CallManager リリース 3.0(1) のゲートキーパー制御はクラスタ間トランクだけに使用できることに注意してください。 ゲートキーパー制御は他のデバイスにも設定できますが、設定はサポートされていません。

アドミッション拒否(ARJ)

ARJ は、Cisco CallManager がゲートキーパーに登録されているが電話のコールを送信できないときに発行されます。 ゲートキーパーによって ARJ が発行されている場合、ゲートキーパーの設定の問題に注目する必要があります。 ただし、次のトラブルシューティングの一般的なガイドラインがあります。

  1. ゲートウェイからゲートキーパーへの IP 接続を確認します。

  2. show gatekeeper status で ゲートキーパーの状態が稼働中になっているか確認します。

  3. ゾーン サブセットがゲートキーパーに定義されていることを確認します。 定義されている場合、ゲートウェイのサブネットが、許可されているサブネットに含まれていることを確認します。

登録拒否(RRJ)

RRJ は、Cisco CallManager がゲートキーパーに登録できない場合に発行されます。 ゲートキーパーによって RRJ が発行されている場合、ゲートキーパーの設定の問題に注目する必要があります。

ただし、次のトラブルシューティングの一般的なガイドラインがあります。

  1. ゲートウェイからゲートキーパーへの IP 接続を確認します。

  2. show gatekeeper status で ゲートキーパーの状態が稼働中になっているか確認します。

  3. ゾーン サブセットがゲートキーパーに定義されていることを確認します。 定義されている場合、ゲートウェイのサブネットが、許可されているサブネットに含まれていることを確認します。

ボイスメール パイロット番号にダイヤルすると ファースト ビジーの状態となる

一部の変更を行ったあと、Call Manager を停止して再開します。utel、ulite、ulogremover、および upilot プロセスを確実に開始します。 これは、CM 2.4.3 および uone 4.1e の送信者によってラボでテストされています。 基本的に UM デバイスはプロセスが再起動しない限り Call Manager に再登録しません。

ケース スタディ I: Cisco IP Phone と Cisco IP Phone 間のクラスタ内コール

このケース スタディでは、クラスタ内コールと呼ばれる、1 つのクラスタ内の 2 台の Cisco IP Phone 間のコール フローについて詳しく説明します。 このケース スタディでは、Cisco CallManager と Cisco IP Phone の初期化、登録、およびキープアライブ プロセスについても説明します。 これに続いて、クラスタ内コール フローについて詳細に説明します。 これらのプロセスは、以前の項で説明したトレース ユーティリティおよびツールを使用して説明されます。

トポロジの例

次の図は、このケース スタディのサンプル トポロジを図示しています。 図で Cluster 1 および Cluster 2 という 2 台のクラスタがあります。 Cluster 1 上の 2 つの Cisco CallManager は CCM3 および CCM4 と呼び、Cluster 2 の 2 つの Cisco CallManager には CCM1 および CCM2 という名前を付けます。 このケース スタディで収集されたトレースは、Cluster 2 にある CCM1 からのものです。 コール フローは Cluster 2 にある 2 台の Cisco IP Phone に基づいています。 これら 2 台の Cisco IP Phone の IP アドレスは、それぞれ 172.16.70.230(電話番号 1000)と 172.16.70.231(電話番号 1001)です。

ios_gatekeeper.gif

Cisco IP Phone 初期化プロセス

Cisco IP Phone の初期化(または「boot up」)プロセスを以下に詳しく説明します。

  1. 初期化の際に、Cisco IP Phone が DHCP サーバに IP アドレス、DNS サーバ アドレス、TFTP サーバ名またはアドレス(もしあれば)を取得するための要求を送信します。 オプションは、DHCP サーバ(オプション 066、オプション 150 など)に設定されます。 また、デフォルト ゲートウェイ アドレスが DHCP サーバに設定されていれば、それも取得します(オプション 003)。

  2. TFTP の DNS 名が DHCP によって送信された場合は、その名前を IP アドレスにマッピングするために DNS サーバの IP アドレスが必要です。 DHCP サーバが TFTP サーバの IP アドレスを送信する場合は、この手順を省略します。 このケース スタディでは、DNS が設定されていないため、DHCP サーバは TFTP の IP アドレスを送信しました。

  3. TFTP サーバ名が DHCP 応答に含まれていない場合、Cisco IP Phone ではデフォルト サーバ名が使用されます。

  4. 設定ファイル(.cnf)は TFTP サーバから取得されます。 すべての .cnf ファイルが SEP<mac_address>.cnf という名前になります。ここで、「SEP」は Selsius Ethernet Phone を指す略語です。 その電話機を初めて Cisco CallManager に登録する場合、デフォルト ファイル SEPdefault.cnf が Cisco IP Phone にダウンロードされます。 このケース スタディでは、1 台めの Cisco IP Phone に IP アドレス 172.16.70.230(MAC アドレスは SEP0010EB001720)を使用し、2 台めの Cisco IP Phone に IP アドレス 172.16.70.231(MAC アドレスは SEP003094C26105)を使用します。

  5. すべての .cnf ファイルにプライマリとセカンダリの Cisco CallManager の IP アドレスが含まれています。 Cisco IP Phone は IP アドレスを使用してプライマリ Cisco CallManager に接続して登録します。

  6. Cisco IP Phone を Cisco CallManager に接続して登録すると、Cisco CallManager から実行する実行ファイルのバージョン(ロード ID と呼ぶ)が Cisco IP Phone に通知されます。 指定されたバージョンが Cisco IP Phone 上の実行ファイルのバージョンと一致しない場合、Cisco IP Phone は TFTP サーバに新しい実行ファイルを要求し、自動的にリセットします。

次のスニファ トレースの例は、電話機の初期化プロセスの概要を示しています。 このトレースの例は、このケース スタディのサンプル トポロジを使用していませんが、Cisco IP Phone の初期化プロセス中に起きる一連のイベントの例を示しています。

sniffer_trace.gif

Skinny ステーションの登録手順

Cisco IP Phone は Cisco Skinny Station Protocol を使用して Cisco CallManager と通信します。 登録プロセスによって、Cisco IP Phone などの Skinny ステーションで、Cisco CallManager に存在を通知し、コールの送信を可能にできるようになります。 次の図は、Cisco IP Phone (「station」)と Cisco CallManager の間で交換されるさまざまなメッセージを示します。

/image/gif/paws/30266/skinny.gif

Skinny ステーション登録プロセスの主要なメッセージを次の表に示します。

Skinny ステーション登録プロセスの説明
メッセージ 説明
Station Register ステーションは制御 Cisco CallManager に存在をアナウンスするメッセージを送信します。
Station Reset Cisco CallManager はこのメッセージを送信して、ステーションにプロセスをリセットするように指示します。
Station IP Port ステーションは、RTP ストリームに使用される User Datagram Protocol(UDP、ユーザ データグラム プロトコル)のポートを Cisco CallManager に提供するためにこのメッセージを送信します。
Station Register Acknowledge Cisco CallManager は、ステーションの登録を許可するためにこのメッセージを送信します。
Station Register Reject Cisco CallManager はこのメッセージを送信して、指定した電話機から試行された登録を拒否します。
 
char text[StationMaxDisplayTextSize]; 

};
各記号の意味は次のとおりです。 text は最大 33 バイトの文字列で、登録が拒否された理由の文字による説明を含みます。
Station Capabilities Request Cisco CallManager はこのメッセージを送信して、ステーションの現在の機能を要求します。 ステーションの機能には、圧縮標準および他の H.323 機能が含まれている可能性があります。
Station Version Request ステーションはこのメッセージを送信して、ステーション用のソフトウェア ロードのバージョン番号を要求します。
Station Version Response Cisco CallManager はこのメッセージを送信して、ステーションに適切なソフトウェア バージョン番号を通知します。
Station Capabilities Response ステーションはこのメッセージを Cisco CallManager に送信して、ステーション機能の要求に応答します。 ステーションの機能は Cisco CallManager にキャッシュされ、H.323 準拠の端末を使用して端末機能をネゴシエートするために使用されます。
Station Button Template Request ステーションはこのメッセージを送信して、特定の端末や Cisco IP Phone のボタン テンプレート定義を要求します。
Station Button Template Response Cisco CallManager はこのメッセージを送信して、ステーションに含まれるボタン テンプレート情報を更新します。
Station Time Date Request ステーションはこのメッセージを送信して、内部で使用しテキスト文字列として表示する現在の日時を要求します。
Station Define Time and Date Cisco CallManager はこのメッセージを使用して、ステーションに日付と時刻情報を提供します。 これによってステーションに時刻の同期を提供します。

クラスタ内のCisco IP Phone 同士のコールフロー

ここでは、同じクラスタ内での 1 台の Cisco IP Phone(電話番号 1000) から別の Cisco IP Phone(電話番号 1001)へのコールについて説明します。 クラスタは、1 個の共通のパブリッシャ SQL データベースおよび多くのサブスクライバ SQL データベースを備えた Cisco CallManager のグループです。

サンプル トポロジでは、CCM1 はパブリッシャで、CCM2 はサブスクライバです。 2 台の Cisco IP Phone(1000 および 1001)はそれぞれ CCM1 および CCM2 に登録されます。 コール フローを次の図に示します。 クラスタ内の 2 つの Cisco CallManager は Intra-Cluster Control Protocol(ICCP)を使用して相互に通信します。 Cisco IP Phone をオフフックにすると、Cisco CallManager と通信する制御 Skinny ステーション セッション(基盤プロトコルとして TCP を使用)が開きます。 コール制御シグナリングが 2 台の Cisco IP Phone とそれぞれに対応する Cisco CallManager 間に確立された後、次の図に示すように 2 台の電話機の間で直接の RTP ストリームのフローが開始します。 このクラスタ内コールの Skinny ステーション コール フローのメッセージは、次のセクションで説明します。

/image/gif/paws/30266/1000_calls_1001.gif

コールフローの間に Cisco IP Phone 同士で行われる Skinny ステーション メッセージの交換

次の図は、2 台の Skinny ステーション間のメッセージのサンプル交換を示します。 Skinny ステーション、つまり Cisco IP Phone は Cisco CallManager への接続を開始し、次に Cisco CallManager は、宛先の Skinny ステーションとの制御セッションを開く前に、番号分析を実行します。 次の図に示すように、Skinny ステーションのメッセージは、簡単な英語を使用して書かれているため、容易に理解できます。 このため、これらのメッセージはこの項では説明しません。 ただし、これらのコール フローの Skinny ステーション メッセージは、後の項でトレースを確認する場合に詳細に説明します。

/image/gif/paws/30266/call_flow.gif

Cisco CallManager 初期化プロセス

このセクションでは、Cisco CallManager の初期化プロセスを CCM1(IP アドレス 172.16.70.228 によって識別)でキャプチャしたトレースを使用して説明します。 すでに説明したように、SDI トレースはエンドポイント間で送信されるすべてのパケットに関する詳しい情報を出力するため、非常に効果的なトラブルシューティング ツールです。 このセクションでは、Cisco CallManager を初期設定する場合に発生するイベントについて説明します。 トレースの読み方を理解することは、さまざまな Cisco CallManager プロセス、および会議、コール転送などサービスでのこれらのプロセスの影響を適切にトラブルシューティングするために役立ちます。

Cisco CallManager SDI トレース ユーティリティから次のメッセージは、Cisco CallManager の内の 1 台(この場合、CCM1)の初期化プロセスを表しています。 次の各メッセージの説明を確認してください。

  • 最初のメッセージは、Cisco CallManager が初期化プロセスを開始したことを示します。

  • 2 番目のメッセージは、Cisco CallManager がデフォルトのデータベース値を読み取ることを示します。これは、プライマリ データベースまたはパブリッシャ データベース(この例の場合)です。

  • 3 番目のメッセージは、Cisco CallManager が TCP ポート 8002 でさまざまなメッセージをリッスンしたことを示します。

  • 4 番目のメッセージは、これらのメッセージことをリッスンした後に、Cisco CallManager がリストに 2 番目の Cisco CallManager CCM2 (172.16.70.229)を追加したことを示します。

  • 5 番目のメッセージは、Cisco CallManager が起動し、Cisco CallManager バージョン 3.0.20 を実行していることを示します。

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3.0(0.20)> started

自己開始プロセス

Cisco CallManager が稼働すると、それ自体で動作する他のプロセスを開始します。 これらのプロセスには、MulticastPoint Manager、UnicastBridge Manager、番号分析、ルート リストなどがあります。 これらのプロセスで説明されるメッセージは、Cisco CallManager の機能に関連する問題をトラブルシューティングするときに非常に役立つことがあります。

たとえば、ルート リストが機能を停止し、使用できないとします。 この問題をトラブルシューティングするには、これらのトレースをモニタして、Cisco CallManager が RoutePlanManager を起動したか、ルート リストをロードしようとしているかどうかを確認します。 次の設定例では、RouteListName「ipwan」および RouteGroupName「ipwan」をロードして、開始します。

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''

次のトレースは、H.323 デバイスとされ、Cluster 1 にある CCM3 を示すデバイス 172.16.70.245 を追加する RouteGroup を示します。 このケース スタディでは、RouteGroup は Cisco IOS ゲートキーパーの許可を受けてコールを Cluster 1 にある CCM3 にルーティングするために作成されています。 Cluster 1 上にある Cisco IP Phone へのコールのルーティングで問題が発生した場合は、次のメッセージが問題の原因を特定する際に役立ちます。

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts

初期化プロセスの一部は、Cisco CallManager が DN を追加していることを示しています。 これらのメッセージを確認すると、Cisco CallManager がデータベースから電話番号を読み取ったかどうかを判別できます。

16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, 
NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started

次のトレースでは、Cisco CallManager のデバイス マネージャが静的に 2 台のデバイスを初期化しています。 IP アドレス 172.17.70.226 のデバイスはゲートキーパーで、IP アドレス 172.17.70.245 のデバイスは異なるクラスタにある別の Cisco CallManager です。 この Cisco CallManager は、H.323 ゲートウェイとしてこの Cisco CallManager に登録されます。

16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245

Cisco CallManager 登録手順

SDI トレースでは、登録プロセスも重要な要素です。 デバイスは電源がオンになると、DHCP を介して情報を取得し、TFTP サーバに接続して自分の .cnf ファイルを取得してから、cnf で指定されている Cisco CallManager に接続します。 デバイスは、MGCP ゲートウェイ、Skinny ゲートウェイ、または Cisco IP Phone の可能性があります。 したがって、デバイスが Cisco AVVID ネットワークで正常に登録されたかどうかを検出できることが重要です。

次のトレースでは、Cisco CallManager は登録用の新しい接続を受信しています。 登録するデバイスは、「MTP_nsa-cm1」(CCM1 上の MTP サービス)と 「CFB_nsa-cm1」(CCM1 上の会議ブリッジ サービス)です。 これら Cisco CallManager で動作しているソフトウェア サービスですが、内部的には異なる外部サービスとして扱われるため、TcpHandle、ソケット番号、およびポート番号、そしてデバイス名も割り当てられます。

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, 
Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, 
Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

次のトレースでは、 Skinny ステーションメッセージが Cisco IP Phone と Cisco CallManager の間で送信されます。 Cisco IP Phone(172.16.70.231)は Cisco CallManager に登録されています。 詳細については、この項の Skinny ステーションメッセージの説明を参照してください。 Cisco CallManager が Cisco IP Phone からの登録要求を受信すると、このデバイスに TcpHandle 番号を割り当てます。 この番号は、デバイスまたは Cisco CallManager が再起動されるまでそのまま残ります。 したがって、16 進数で表示されるデバイスの TcpHandle 番号を検索または追跡すれば、特定のデバイスに関連するすべてのイベントを追跡できます。 また、Cisco CallManager が Cisco IP Phone にロード ID を提供することに注意してください。 このロード ID に基づいて、Cisco IP Phone がデバイスに対応する実行ファイルを実行します(TFTP サーバから取得します)。

16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, 
Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:57.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, 
TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr 
LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" 
Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) 
tcpHandle=0x4fbbc30

Cisco CallManager キープアライブ プロセス

ステーション、デバイス、またはサービスおよび Cisco CallManager のどれも、相互間の通信チャネルの情報を維持するために次のメッセージを使用します。 メッセージは、Cisco CallManager とステーション間の通信リンクがアクティブ状態を維持していることを確認するキープアライブ シーケンスを開始するために使われます。 次のメッセージは、Cisco CallManager またはステーションのいずれからでも発信できます。

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=
[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=
[1,85,1]

次のトレースのメッセージは、Cisco CallManager とステーション間の通信リンクがアクティブ状態であることを示すキープアライブ シーケンスを示しています。 再度確認しますが、これらのメッセージは Cisco CallManager またはステーションのどちらからでも発信できます。

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Cisco CallManager イントラクラスタ・コール・フロー・トレース

次の SDI トレースはクラスタ内コールのフローを詳細に調べています。 コール フロー内の Cisco IP Phone は DN、tcpHandle、および IP アドレスで識別できます。 Cluster 2 に ある Cisco IP Phone(DN = 1001、tcpHandle = 0x4fbbc30、IP アドレス = 172.16.70.231)が、同じクラスタにある別の Cisco IP Phone(DN = 1000、tcpHandle = 0x4fbb150、IP アドレス = 172.16.70.230)をコールします。 トレースでデバイスを追跡するには、デバイスの TCP ハンドル値、タイムスタンプ、または名前を調べます。 デバイスの TCP ハンドル値は、デバイスがリブートされるかオフラインになるまで変わりません。

次のトレースは、Cisco IP Phone(1001)がオフフックになっていることを示しています。 次のトレースは、Cisco IP Phone に表示される固有のメッセージ、TCP ハンドル、発信番号を示しています。 ユーザはまだ番号をダイヤルしていないため、この時点では発信番号はありません。 次の情報は、Cisco IP Phone と Cisco CallManager 間の Skinny ステーション メッセージの形式です。

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

次のトレースでは、Cisco CallManager から IP Phone へ送信される Skinny ステーション メッセージを示します。 最初のメッセージは、発信者側の Cisco IP Phone のランプをオンにします。

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

Cisco CallManager によって stationOutputCallState メッセージが使用され、特定のコール関連情報をステーションに通知します。

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

stationOutputDisplayPromptStatus メッセージが Cisco CallManager によって使用され、コール関連のプロンプト メッセーが Cisco IP Phone に表示されます。

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

Cisco CallManager によって stationOutputSelectSoftKey メッセージが使用され、Skinny ステーションで一連のソフトキーを選択できるようにします。

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

次のメッセージは、Cisco CallManager によって使用され、表示用の正しい行コンテンツに関して Skinny ステーションに指示します。

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

次のメッセージは、番号分析プロセスで着信番号の識別、データベース内のルーティング一致の確認ができる状態になっていることを示しています。 エントリ、cn=1001 は発信側番号を表します。 dd="" は、ダイヤルした番号を表し、着信側番号になります。 ことに StationInit メッセージは電話機から送信され、StationD のメッセージは Cisco CallManager から送信され、そして番号分析は Cisco CallManager によって実行されることに注意します。

16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

次のデバッグ メッセージは、Cisco CallManager が内部ダイヤル トーンを発信側 Cisco IP Phone で鳴らしていることを示します。

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

Cisco CallManager が受信メッセージを検出して、Cisco IP Phone でキーパッド ボタン 1 が押されたことを認識すると、ただちに出力トーンを停止します。

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

Cisco CallManager で一致するのに十分な桁数を受信した場合、表形式で番号分析の結果を提供します。 この時点以降に電話機で押された追加の番号は、すでに一致が見つかっているため、Cisco CallManager によって無視されます。

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

次のトレースは Cisco CallManager が着信側の電話にこの情報を送信していることを示します(電話機は tcpHandle 番号で識別されます)。

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150

次のトレースでは、着信側の Cisco IP Phone で着信コールを示すためにランプが点滅するように Cisco CallManager が指示していることを示します。

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampBlink tcpHandle=0x4fbb150

次のトレースでは、Cisco CallManager は呼び出し音、ディスプレイ通知などのコール関連情報を着信側の Cisco IP Phone に提供しています。 ここでも、トレース全体で同じ tcpHandle が使用されているため、すべてのメッセージが同じ Cisco IP Phone に送信されていることを確認できます。

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

Cisco CallManager は、発信側の Cisco IP Phone にも同様の情報を提供していることに注意してください。 ここでも、Cisco IP Phone を区別するために tcpHandle が使用されます。

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30

次のトレースでは、Cisco CallManager は、接続が確立されたことを通知するために発信側の Cisco IP Phone へのアラートの通知や、呼び出し音を提供します。

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

この時点で、着信側の Cisco IP Phone がオフフックになります。 このため、Cisco CallManager は、発信者側への呼出音の生成を停止します。

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

次のメッセージでは、Cisco CallManager が Skinny ステーションに Unicast RTP ストリームの受信を開始するように指示しています。 そのために、Cisco CallManager は着信側の IP アドレス、コーデック情報、およびパケット サイズ(ミリ秒)を提供します。 PacketSize は整数で、RTP パケットを作成するために使用されるミリ秒単位のサンプリング時間です。

通常、この値は 30 ミリ秒に設定されます。 この事例では、20 ミリ秒に設定されています。

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 
myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

同様に、Cisco CallManager は着信側(1000)に情報を提供します。

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 
myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

Cisco CallManager は RTP ストリーム用のオープン チャネルを確立するために、着信側から確認応答メッセージと着信側の IP アドレスを受信します。 このメッセージは、Skinny ステーションに関する 2 種類の情報を Cisco CallManager に通知します。 まず、オープン処理のステータスが通知されます。 次に、リモート エンドへの転送に使用される受信ポートのアドレスと番号が通知されます。 RTP ストリームのトランスミッタ(発信側)の IP アドレスは ipAddr で、PortNumber は RTP ストリーム トランスミッタ(発信側)の IP ポート番号です。

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2

次のメッセージは、指定されたリモート Cisco IP Phone の IP アドレスとポート番号にオーディオ ストリームの送信を開始するようにステーションに指示するために Cisco CallManager によって使用されます。

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 
myIP: e74610ac 
(172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

次のトレースでは、上記のメッセージが着信側に送信されています。 これらのメッセージの後に、RTP メディア ストリームが着信側と発信側の間で開始されたことを示すメッセージが続きます。

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 
myIP: e64610ac 
(172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

最後に発信側の Cisco IP Phone はオンフックになり、これにより、Skinny ステーションと Cisco CallManager 間の制御メッセージと Skinny ステーション間の RTP ストリームが終了します。

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

ケース スタディ II: Cisco IP Phone と Cisco IOS ゲートウェイとのコール

前のケース スタディでは、クラスタ内コールのコール フローとトラブルシューティングの方法を詳細に説明しました。 このケース スタディでは、Cisco IP Phone から Cisco IOS ゲートウェイを経由して、ローカル PBX を介して接続している電話機または PSTN 上のどこかにある電話機へのコールを検証します。 概念的には、コールが Cisco IOS ゲートウェイに到達すると、ゲートウェイは Foreign Exchange Station(FXS)ポートまたは PBX のどちらかに繋がっている電話機にコールを転送します。 PBX に転送されたコールは、ローカル PBX に繋がっている電話機で終端するか、または PBX によって PSTN 経由で転送され、PSTN 上で終端します。

トポロジの例

次の図は、このケース スタディのサンプル トポロジを示しています。 コールは PSTN に Cisco IOS ゲートウェイおよびインターフェイスを介してPSTN にルーティングされ、PBX は T1/CAS または T1/PRI です。 ゲートウェイはモデル 26XX、36XX、53XX または 6K です。

/image/gif/paws/30266/ios_gatekeeper2.gif

コール・フロー・トレース

このセクションでは、Cisco CallManager トレース ファイル CCM000000000 の例に、コール フローについて解説します(ファイルの場所については前項を参照してください)。 詳細なトレース情報については以前のケース スタディ(初期化、登録、キープアライブ メカニズムなど)ですでに説明しているので、このケース スタディのトレースではコール フロー自体にだけ注目します。

このコール フローでは、Cluster 2 にある Cisco IP Phone(電話番号 1001)で PSTN のどこかにある電話機(電話番号を 3333)にコールを発信しています。 トレースでデバイスを追跡するには、デバイスの TCP ハンドル値、タイムスタンプ、または名前を調べます。 デバイスの TCP ハンドル値は、デバイスがリブートされるかオフラインになるまで変わりません。

次のトレースでは、Cisco IP Phone(1001)がオフフックになっています。 トレースは、Cisco IP Phone に表示される固有のメッセージ、TCP ハンドル、発信番号を示しています。 ユーザはまだ番号をダイヤルしていないため、この時点では発信番号はありません。

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim ? OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001 

次のトレースでは、ユーザが 3333 をダイヤルしています(数字を 1 つずつダイヤルします)。 番号 3333 は、PSTN ネットワーク上の電話機の宛先番号です。 Cisco CallManager の番号分析プロセスが現在アクティブで、コールをどこにルーティングする必要があるかを検出するために番号を分析しています。 番号分析の詳細な説明は、前のケース スタディで提供されています。

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

次のトレースでは、番号分析が完了した後、発信側および着信側が一致し、情報が分析されました。

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

次のトレースでは、番号 0 が発信元のロケーションを示し、番号 1 が宛先のロケーションを示しています。 発信ロケーションの帯域幅は BW = 1 を使って判定できます。 値 -1 は、帯域幅が無限であることを暗黙的に示します。 コールが LAN 環境にある Cisco IP Phone から発信されているので、帯域幅は無制限です。 宛先ロケーションの帯域幅は BW = 64 を使って判定できます。 コールの宛先は PSTN にある電話に対するもので、コーデック タイプは G.711 (64Kbps)が使用されます。

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

次のトレースは、発信側および着信側の情報を示しています。 この例では、管理者が「John Smith」などの表示名を設定していないため、発信側の名前と番号は同じです。

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98

次のトレースのレビュー前に、H.323 の意味を理解することが重要です。 簡単な説明として、H.323 セッションを確立する場合に使用される複数のプロトコルがあります。 1 つのプロトコルは H.225 で、主にコール シグナリングに使われ、Q.931 のサブセットです。 もう一つのプロトコルは機能交換に使用される H.245 です。 H.245 の重要な機能の 1 つが、発信側と着信側の間での、G.711、G.729 などの圧縮/復元(コーデック)のタイプ ネゴシエーションです。 機能交換が完了すると、H.245 の次の重要な機能は発信側と着信側の間の UDP のポート ネゴシエーションの実施です。

次のトレースは、H.323 コードが初期化され、H.225 セットアップ メッセージを送信していることを示しています。 従来の HDLC SAPI メッセージ、16 進表記の着信側の IP アドレス、およびポート番号も確認できます。

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)

次のトレースは、発信側および着信側の情報と H.225 アラート メッセージを示しています。 また、Cisco IP Phone の 16 進数値の IP アドレスへのマッピングを示します。 172.16.70.231 は、Cisco IP Phone(1001)の IP アドレスです。

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)

次のトレースはこのコール(G.711 に使用する圧縮タイプを示しますか。-関連法規)。

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

H.225 アラート メッセージが送信されると、 H.323 の次の部分が初期化されます。 H.245。 次のトレースは、発信側および着信側の情報と H.245 メッセージを示しています。 TCP のハンドル値が以前と同じであることに注意してください。これは、同じコールが続いていることを示します。

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding

次のトレースは、H.225 接続メッセージを示し、同時に前に説明したほかの情報も示しています。 H.225 接続メッセージが受信されている場合、コールが接続されています。

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 
myIP: e74610ac 
(172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 
16758 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)

次のメッセージは、Cisco IP Phone(1001)からのオンフック メッセージを受信していることを示しています。 オンフック メッセージを受信するとすぐに、H.225 と Skinny 接続解除メッセージが送信され、H.225 メッセージの全文が表示されます。 この最後のメッセージはコールが終了したことを示します。

15:20:27.296 CCM|StationInit - InboundStim ? OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending 
disconnect to (64,5) and remove 
connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP:
 e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol

Cisco IOS Gatekeeper のdebug messages およびshow コマンド

前の項では、Cisco CallManager SDI トレースを詳しく説明しました。 このケース スタディのトポロジでは、Cisco IOS ゲートキーパーで debug ras コマンドがオンになっています。

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco CallManager(172.16.70.228)に対するアドミッション要求(ARQ)を受信し、その他の正常な RAS メッセージが後続していることを示しています。 最後に、Cisco IOS ゲートキーパーがアドミッション確認(ACF)メッセージを Cisco CallManager に送信しています。

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

次のデバッグ メッセージは、コールが進行中であることを示しています。

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 
55 from 172.16.70.228883

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco CallManager(172.16.70.228)から接続解除要求(DRQ)を受信したこと、および Cisco IOS ゲートキーパーが Cisco CallManager に接続解除確認(DCF)を送信したことを示します。

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 
from 172.16.70.228883

Cisco IOS ゲートキーパーに対する show gatekeeper endpoints コマンドは、4 つの Cisco CallManager がすべて Cisco IOS ゲートキーパーに登録されていることを示します。 このケース スタディのトポロジでは、4 台の Cisco CallManager があり、各クラスタ内に 2 台ずつあることに注意してください。 この Cisco IOS ゲートキーパーには 2 つのゾーンがあり、各ゾーンに 2 台の Cisco CallManager があります。

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW
H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW
H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4

Cisco IOS Gateway のdebug messages および show コマンド

前の項では、Cisco IOS ゲートキーパーの表示コマンドとデバッグ出力について詳しく説明しました。 ここでは、Cisco IOS ゲートウェイのデバッグ出力と表示コマンドについて説明します。 このケース スタディのトポロジでは、コールが Cisco IOS ゲートウェイを通過します。 Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 debug voip ccapi inoutdebug H225 eventsdebug H225 asn1 などのコマンドのデバッグ出力を以下に示します。

次のデバッグ出力では、Cisco IOS ゲートウェイが Cisco CallManager(172.16.70.228)からの TCP 接続要求を H.225 のポート 2328 で受け入れます。

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 
172.16.70.228:2328 on socket [1]
*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

次のデバッグ出力は、この TCP セッションで、H.225 データが Cisco CallManager から着信していることを示しています。 このデバッグ出力では、使用する H.323 バージョンを示す protocolIdentifier に注意することが重要です。 次のデバッグは、H.323 バージョン 2 が使用されていることを示しています。 着信側と発信側の番号も表示されます。

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:57.177: H225Lib::h225RecvData: Q.931 SETUP received from socket 
[1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:57.185: destinationAddress
*Mar 12 04:03:57.185: {
*Mar 12 04:03:57.185: e164 : "3333"
*Mar 12 04:03:57.185: },
*Mar 12 04:03:57.189: H225Lib::h225RecvData: State changed to [Call Present].

次は、Call Control Application Programming Interface(CCAPi)のデバッグ出力です。 CCAPi は、着信コールを示しています。 着信側および発信側の情報も、次の出力に表示されます。 CCAPi は、デフォルトのダイヤル ピアであるダイヤル ピア 0 に一致します。 CCAPi がダイヤル ピア 0 に一致しているのは、発信番号に対する他のダイヤル ピアが見つからず、デフォルトのダイヤル ピアを使用しているためです。

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, 
calling=1001, fdest=1 
peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, 
*callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, 
guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

CCAPi は、ダイヤル ピア 1 と宛先パターン(着信番号 3333)を照合します。 peer_tag はダイヤル ピアを意味します。 要求パケット内の発信側と着信側の番号に注意してください。

*Mar 12 04:03:57.193: peer_tag=1
*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, 
callParams={called=3333, calling=1001, 
fdest=1, voice_peer_tag=1}, mode=0x0)

次のデバッグ出力は、 H.225 警告メッセージが Cisco CallManager に戻されていることを示します。

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12,
 prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)
-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0
)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, 
dstCallID=0x12, 
disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205: destinationInfo
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: mc FALSE,
*Mar 12 04:03:57.205: undefinedNode FALSE
*Mar 12 04:03:57.205: },

このパケットで、Cisco IOS が H.245 アドレスとポート番号を Cisco CallManager に送信していることに注意してください。 Cisco IOS ゲートウェイは到達不能なアドレスを送信する場合があるため、無音声または片通話になることがあります。

*Mar 12 04:03:57.205: h245Address ipAddress :
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: ip 'AC1046E2'H,
*Mar 12 04:03:57.205: port 011008
*Mar 12 04:03:57.205: },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213:
*Mar 12 04:03:57.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. 
Call state changed to [Call 
Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12,
 dstCallID=0x11, 
disposition=0, tag=0x0)

次のデバッグ出力は、H.245 セッションが開始されていることを示しています。 コーデック ネゴシエーションの機能表示、各音声パケットに含まれるバイト数を確認できます。

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12,
 caps={codec=0xEBFB, 
fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)
-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

次のデバッグ出力は、両方の側が適切にネゴシエートし、160 バイト データの G.711 コーデックで合意したことを示しています。

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, 
srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323 は以下に示すメッセージを接続および接続解除します。

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)
-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-uu-pdu
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-message-body connect :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373: h245Address ipAddress :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.377: ip 'AC1046E2'H,
*Mar 12 04:03:59.377: port 011008
*Mar 12 04:03:59.377: },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)

T1/PRI インターフェイス付き Cisco IOS Gateway

すでに説明したように、Cisco IOS ゲートウェイを経由するコールは 2 タイプあります。 Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次は、Cisco IOS ゲートウェイが T1/PRI インターフェイスを使用する場合のデバッグ出力です。

Cisco IOS ゲートウェイの debug isdn q931 command がオンになっています。 これは、Q.931(ISDN 環境の D チャネルのレイヤ 3 シグナリング プロトコル)を有効にします。 T1/PRI インターフェイスからコールが発信されるたびに、セットアップ パケットが送信される必要があります。 セットアップ パケットには必ずプロトコル記述子 pd = 8 が含まれ、callref 用にランダムな 16 進数値が生成されます。 コールを追跡するために callref が使用されます。 たとえば、2 つのコールが発信された場合、callref の値によって、RX(受信済み)メッセージの対象になっているコールを判別できます。 ベアラ機能 0x8890 は 64 kbps のデータ コールです。 これが 0x8890218F の場合は 56kbs のデータ コールです。 音声コールの場合、これは 0x8090A3 です。 次のデバッグ出力では、ベアラ機能は、音声用である 0x8090A3 です。 着信側と発信側の番号も表示されます。

callref では、最初の数字に異なる値を使用し(TX と RX を識別するため)、2 番めの値は同じです(SETUP の最後の数字は 0、CONNECT_ACK も 0 です)。 ルータはベアラ チャネル(B チャネル)を割り当てる際に PSTN または PBX に完全に依存します。 PSTN または PBX がルータにチャネルの割り当てない場合、コールはルーティングされません。 このケース スタディでは、交換機から受信される CONNECT メッセージに、ALERTING 用に受信されたものと同じ参照番号(0x800B)が付いています。 最後に、コールが接続解除されるとき、DISCONNECT メッセージの交換後に RELEASE メッセージと RELEASE _COMP メッセージが続くことを確認できます。 RELEASE_COMP のメッセージの後にコール拒否の原因 ID が表示されます。 原因 ID は 16 進数値です。 原因の意味は 16 進数値をデコードして見つけることができ、プロバイダーと追うことによって確認できます。

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ?1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ?3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept,
 call blocked group restriction 

T1/CAS インターフェイス付き Cisco IOS Gateway

すでに説明したように、Cisco IOS ゲートウェイを経由するコールは 2 タイプあります。 Cisco IOS ゲートウェイは T1/CAS または T1/PRI のいずれかのインターフェイスを使用して PSTN または PBX に接続します。 次は、Cisco IOS ゲートウェイが T1/CAS インターフェイスを使用する場合のデバッグ出力です。 Cisco IOS ゲートウェイでは debug cas がオンになっています。

次のデバッグ メッセージは、Cisco IOS ゲートウェイがオフフック信号を交換機に送信していることを示しています。

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111) 

次のデバッグ メッセージは、交換機が Cisco IOS ゲートウェイから閉ループ信号を受信後、ウィンクを送信していることを示しています。

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

次のデバッグ メッセージは、Cisco IOS ゲートウェイがオフフックしようとしていることを示しています。

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

次は、コールが進行中の Cisco IOS ゲートウェイでの show call active voice brief の出力です。 着信側と発信側の番号およびその他の有用な情報も表示されます。

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid: <peer_id> <dir> <addr> <state> tx: <packets>/<bytes>
 rx:<packets>/<bytes>
<state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> 
delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> (payload size) 
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548 
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm

国際番号にダイヤルした後ビジーシグナルが発生する

問題

ユーザは自分の DT-24+ ゲートウェイに割り当てられた適切なルート パターンのある CM 2.4.4 を持っています。 市内電話および米国内長距離電話は問題なくかけることができます。 しかし、国際電話の番号を押すと、ユーザが電話番号の桁を打つ場合は、一時停止とビジー信号が聞こえます。

解決策

これは CO スイッチがコール IE (情報要素)で正しく処理する方法がわからない場合にすでに発生しています。 これは、DT24+ の SPAN パラメータでCall Manager の発信側の IE のタイプを [Set Calling and Called type DN to unknown] に設定することで修正することが可能です。

ケース スタディ III: クラスタ間 Cisco IP Phone コール

前のケース スタディでは、クラスタ内コール、および Cisco IOS ゲートウェイを経由したローカル PBX または PSTN のどこかでに繋がっている電話への Cisco IP Phone からのコールのコール フローとトラブルシューティングの方法は詳しく説明しました。 このケース スタディでは、Cisco IP Phone から別のクラスタにある別の Cisco IP Phone コールを送信します。 このようなコールは、クラスタ間の Cisco IP Phone コールです。

トポロジの例

次は、このケース スタディで使用されるサンプル トポロジです。 このトポロジーでは 2 個のクラスタがあり、 各クラスタに 2 台の Cisco CallManager があります。 また、Cisco IOS ゲートウェイおよび Cisco IOS ゲートキーパーが所定の場所にあります。

/image/gif/paws/30266/ios_gatekeeper3.gif

内部クラスタ H.323 コミュニケーション

トポロジで確認できるように、Cluster 1 の Cisco IP Phone はクラスタ Cluster 2 の Cisco IP Phone にコールを発信します。クラスタ間の Cisco CallManager 通信は H.323 バージョン 2 プロトコルを使用して実行します。 また、アドミッション制御用の Cisco IOS ゲートキーパーがあります。 デバッグ出力と show コマンド、および Cisco IOS ゲートキーパーと Cisco IOS ゲートウェイと Cisco CallManager デバイス間の対話の詳細な説明は以前の項で確認できます。

コール フロー プロセスを次の図に示します。 Cisco IP Phone は、Skinny ステーション プロトコルによって Cisco CallManager と通信でき、Cisco CallManager は H.323 RAS プロトコルを使用して Cisco IOS ゲートキーパーと通信できます。 アドミッション要求(ARQ)メッセージが Cisco IOS ゲートキーパーに送信され、ゲートキーパーはクラスタ間コールが H.323 バージョン 2 プロトコルを使用して発信できることを確認したあと、アドミッション確認(ACF)メッセージを送信します。 これが終了すると、異なるクラスタの Cisco IP Phone の間の RTP プロトコルを使用する音声パスが作成されます。

/image/gif/paws/30266/gatekeeper_flow.gif

コール・フロー・トレース

ここでは、CCM000000000 ファイルにキャプチャされる SDI トレースの例を使用して、コール フローについて説明します。 このファイルの場所は、前の項で確認できます。 詳細なトレース情報については以前のケース スタディ(初期化、登録、キープアライブ メカニズムなど)ですでに説明しているので、このケース スタディで説明するトレースではコール フロー自体にだけ注目します。

このコール フローでは、Cluster 2 にある Cisco IP Phone(2002)が Cluster 1 にあるCisco IP Phone(1001)にコールを発信します。トレースでは、デバイスの TCP のハンドル値、タイムスタンプ、または名前でトレースを検索してデバイスを追跡できることを確認してください。 デバイスの TCP ハンドル値は、デバイスがリブートされるかオフラインになるまで変わりません。

次のトレースでは、Cisco IP Phone(2002)がオフフックになっています。 トレースは、Cisco IP Phone に表示される固有のメッセージ、TCP ハンドル、発信番号を示しています。 着信番号(1001)、H.225 接続、および H.245 確認メッセージは、次のデバッグ出力で確認できます。 コーデックタイプは G.711 ですか。-関連法規。

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310,
 Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

発信側番号および着信側番は、IP アドレスと 16 進数に関連付けられ、次のトレースで確認できます。

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310
 myIP: e74610ac 
(172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 

次のトレースは、Cisco IP Phone(2002)のパケット サイズと MAC アドレスを示しています。 次のトレースの後では切断され、その後オンフックになります。

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to 
(64,2) and remove 
connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2)
 from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

失敗したコールフロー

次の項では、SDI トレースで示されているように、失敗したクラスタ間コール フローについて説明します。 次のトレースでは、Cisco IP Phone(1001)がオフフックになっています。 TCP ハンドルが Cisco IP Phone に割り当てられます。

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampOn tcpHandle=0x4fbbc30

次のトレースでは、ユーザが着信側 Cisco IP Phone の番号(2000)をダイヤルし、番号分析プロセスによって番号の一致が試行されています。

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

番号分析が完了し、結果が次のトレースに表示されます。 次の PotentialMatches=NoPotentialMatchesExist 参照は、Cisco CallManager がこの電話番号の一致を見つけられなかったことを示していることに注意することが重要です。 最後に、リオーダー音が発信側(1001)に送信され、オンフック メッセージが続きます。

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

コールの詳細な記録

ここでは、コール詳細レコード(CDR)およびコール管理レコード(CMR、別名 Diagnostic CDR)に関する詳細情報を説明します。

CDR レコードが後処理アクティビティで使用するためにデータベースに書き込まれます。 これらのアクティビティには多くの機能がありますが、主に課金およびネットワーク解析です。

データベースは Microsoft SQL サーバ 7.0 データベースです。 データベースへのアクセスはオープン データベース コネクティビティ(ODBC)によって行われます。

アクセスは、データベースのすべてのテーブルへは読み取り専用方式、CDR および CMR テーブルには読み書き方式が提供されます。

CDR レコードのデータを使用するには、CDR がレポートしているデバイスのタイプに関する情報を取得するために、データベース内の他のテーブルを参照する必要があります。 デバイス テーブル内のデバイスと CDR レコードにリストされている IP アドレス間のこの相関は簡単ではなく、この項で後で説明します。

レコードの書き込み

個々の Cisco CallManager の設定で一貫している方法でコールが行われると、Cisco CallManager は CDR レコードを SQL データベースに書き込みます。 この設定は、 Cisco CallManager Administration の [Service Parameters] 画面で行われます。

すべてのレコードがクラスタのプライマリ データベースに書き込まれます。 プライマリ データベースが使用できない場合は、レコードは他のバックアップ データベースのいずれかに書き込まれます。 プライマリ データベースが使用可能になると、新しいレコードの書き込みはプライマリ データベースで継続され、ローカルで保存したレコードをプライマリ移動します。

レコードの読み込み

SQL のデータベースからデータを読み取るための最も簡単な方法は、ODBC を使用することです。 優れた接続文字列は、次のようなものです。

DRIVER={SQL Server};SERVER=machineX;DATABASE=CCM0300

正しいデータベース名を使用してください。 Cisco CallManager リリース 3.0(1) バージョンのソフトウェアを既存のインストールに上書きしてインストールした場合、新しいインストールからコールを発信したときにデータベースが移行されている可能性があります。 この場合は、古いデータベースがまだ存在し、新しいデータベースも存在します。 名前は、名前の数に 1 を追加することによって異なります。 たとえば、元の名前が CCM0300 です。 移行後は、新しいデータベース名が CCM0301 です。 数字の最も大きなデータベースが使用される必要があります。

クラスタによって現在使用中のプライマリ データベース(マシンと名前)は、Cisco CallManager Administration の [Details] ボタンをクリックして確認できます([Help] をクリックして [Details] ボタンがある [Welcome] 画面に移動します)。 データベースをホストしているマシンのレジストリも確認できます。 レジストリ キー \DBConnection0 と呼ばれる項目は \HKEY_LOCAL_MACHINE\Software\Cisco Systems Inc.\DBL にあります。 この文字列項目は、プライマリ データベースのマシン名とデータベース名を使った上記のような結合文字を含みます。

アクセスは SQL ユーザを使用して制御されます。 次の表は、Cisco CallManager データベースにアクセスするときに使用する必要のあるユーザ ID とパスワードを指定しています。

テーブル SQl ユーザ ID Password 機能
CallDetailRecord、CallDetailRecordDiagnostic CiscoCCMCDR dipsy 読み取り/書き込み
(その他) CiscoCCMReader cowboys 読み取り専用

レコードの削除

Cisco CallManager では CDR データの後処理はサードパーティ アプリケーションに依存しているため、すべてのアプリケーションがデータの使用を完了したら CDR データを削除する必要があります。 これは、データベースの変更を伴うため CiscoCCMCDR ユーザを使用する必要があります。

CDR レコードが設定された最大値(10,000,000 の CDR レコード)まで蓄積されると、最も古い CDR レコードが毎日の関連 CMR レコードの削除とともに削除されます。

CDR データを分析後に削除した場合は、すべての関連する CMR レコードも削除してください。

テーブル スキーマ

CDR の各フィールドの形式と使用についての詳細は、この項の後半で説明します。

使用されるプライマリ テーブルは、CallDetailRecord テーブル(CDR レコードを保持する)および CallDetailRecordDiagnostic テーブル(CMR レコードを保持する)です。 CallDetailRecord テーブルは、2 つの GlobalCallID 列、 GlobalCallID_callManagerId および GlobalCallID_callIdGlobalCallID_callManagerId を介して CallDetailRecordDiagnostic テーブルと関連付けられています。 CDR ごとに複数の CMR がある可能性があります。

CallDetailRecord テーブルには、コールのエンドポイントおよびその他のコール制御/すべてのコールのルーティング状況に関する情報が保持されます。 CallDetailRecordDiagnostic テーブルには、コールの音声ストリームの品質に関する情報が保持されます。

既知の問題

Cisco CallManager リリース 3.0(1) では CDR データに関する複数の既知の問題があります。 これらのいくつかを次に示します。

IP からデバイス名への変換

CDR テーブルは、コールのエンドポイントの IP アドレスを示します。 これらの IP アドレスは、簡単にデバイス名に変換できないため、デバイスのタイプも判定できません。

オンネットとオフネット

コールが IP ネットワークに完全にとどまったままなのか、または少なくともローカル システム内にあるのかを知ることは困難です。 1 つの方法はコールの両端のデバイス タイプを確認することです。 両方が電話機である場合、オンネットをとどまったと考えられます。 ただし、一方がゲートウェイの場合、より多くの想定を行う必要があります。 ゲートウェイが POTS またはステーション ポートを搭載したアナログ アクセス タイプのデバイスである場合、そのコールの行き先がローカル アナログ電話機だけになる場合があります。また、PSTN から外に出る場合もあります。 ダイヤルした番号を見て、これを、コールがオフネットに移動したとみなすための既知のダイヤル プランに関連付けます。 それ以外の場合、コールはオンネット移行しました。

オフネット番号ダイヤラ

コールがゲートウェイの外に出た場合、ゲートウェイで取得するダイヤルされた桁数は PSTN に送信された番号ではない場合があります。 ゲートウェイは情報処理機能があるので、電話番号を変更する場合があります。 この場合、 Cisco CallManager で認識されないため、CDR ではオフネットに送信された実際の番号が反映されません。

コール詳細レコードのフィールド

ここでは、現在のレコードのフィールドすべてを定義します。 フィールド タイプは Cisco CallManager で使用されているもので、データベース内の CDR レコードで定義されたタイプは必要ありません。 データベース フィールド定義はデータを保存するのに十分であればいいですが、データの解釈にここでのフィールド タイプの定義を考慮する必要があります。

すべての符号なし整数は 32 bit 符号なし整数です。

フィールド データの変換

表示を10 進形式から別の形式への変換する必要のあるフィールドがあります。 ここでは、その値、および変換方法または変換方法の情報の入手できる場所を定義します。

時刻値

すべての時刻値は符号なしの 32 ビット整数として表されます。 この符号なし整数値はデータベースから読み出されて符号付き整数として表示されます。

このフィールドは、Windows NT (2000)システム ルーチンから取得された time_t 値です。 値は協定世界時(UTC)値で、1970 年 1 月 1 日深夜(00:00:00)以降の秒数で表します。

タイム スタンプの解読

Microsoft Excel を使用して、このタイム スタンプ変換を少し簡単に行う式を書くことができます。 値がセル A1 にある場合、他のセルを次のようにすることができます。

= A1 / 86400 + DATE(1970,1,1)

1 日は 86400 秒です。

次に、結果のセルを Excel の日付または時間フィールドの書式にします。

IP Addresses

すべての IP アドレスは符号なし整数としてシステムに保存されます。 データベースは符号付き整数として表示します。 符号付き 10 進値を IP アドレスに変換するには、まず 16 進数に変換します(この値が実際には符号なしの数字であることを考慮します)。 32 bit 16 進数の値は 4 バイトで表します。 4 バイトは逆順(Intel の標準)です。 IP アドレスを求めるには、バイトの順序を逆にして、各バイトを 10 進数に変換します。 この結果の 4 バイトが、ドット付き表記で示される IP アドレスの 4 バイトのフィールドになります。

IP アドレスの下位バイトに最上位ビット セットが含まれている場合、データベースには負数が表示されます。

IP アドレスの変換

  • 例 1:

    たとえば、IP アドレス 192.168.18.188 は次のように表示されます。

    データベースの表示 = -1139627840。

    これは 16 進数値 0xBC12A8C0 に変換します。

    逆順の 16 進数のバイト = C0A812BC

    CO A8 12 BC

    16 進数から 10 進数に変換したバイト = 192.168.18.188、これは 192 168 18 188 として表示されます。

  • 例 2:

    IP address 192.168.18.59

    データベースの表示 = 991078592

    これは 16 進数値 0x3B12A8C0 に変換します。

    逆順のバイト順 = C0A8123B

    C0 A8 12 3B

    16 進数から 10 進数に変換したバイト = 192.168.18.59、これは 192 168 18 59 として表示されます。

CDR フィールド定義

以下の表には、CDR のフィールドの定義が記載されています。

フィールド定義
フィールド 定義
cdrRecordType このレコーのタイプ、符号なし整数、この特定のレコードのタイプを指定します。 これは、Start call record(0)、End call record(1)、または CMR record(2) である場合もあります。
globalCallIdentifier グローバル コール識別子、グローバル コール識別子はどちらも符号なし整数である 2 個のフィールドから構成されます。 値は符号なし整数として扱われる必要があります。 2 つのフィールドは次のとおりです。 符号なし整数の GlobalCallID_CallID、符号なし整数 GlobalCallID_CallManagerID。これらは、コール全体に割り当てられるコール ID です。 すべてのレコードが同じグローバル コール識別子を持つ標準コールに関連付けられています。
origLegCallIdentifier 発信元レッグのコール ID、符号なし整数。これは、コールの発信元レッグを追跡するために使用される固有識別子です。 これはクラスタ内で一義的です。
dateTimeOrigination コール発信元の日時、符号なし整数。これはコールの発信元デバイスがオフフック時間または外部コールがシステムで最初に認識された時間を表します(これは Setup メッセージを受信されます)。 値は協定世界時(UTC)値で、1970 年 1 月 1 日深夜(00:00:00)以降の秒数で表します。
origNodeId 発信元のノード ID、符号なし整数。このフィールドは、コールの発信元がこのコール時に登録済みの Cisco CallManager クラスタ内のノードを表します。
origSpan 発信元の SPAN またはノード、符号なし整数。コールがゲートウェイ経由で発信されている場合は、このフィールドには発信元のポートまたは SPAN 番号が含まれています。 そうでない場合、このフィールドにはゼロ(0)が含まれます。
callingPartyNumber 発信側番号、25 文字までの文字列。コールの発信元デバイスの電話番号です。
origIpPort 発信側の IP ポート、符号なし整数。このフィールドには、コールの発信元デバイスの IP ポートが含まれています。
origIpAddr 発信側の IP アドレス、符号なし整数。このフィールドには、コールの発信元デバイスの IP アドレスが含まれています。
originalCallingPartyNumberPartition 発信側のパーティション、50 文字までの文字列。このフィールドには、発信側に関連付けられているパーティションが含まれています。
origCause_Location ISDN のロケーション値 、符号なし整数。このフィールドには、原因情報要素のロケーション値が含まれています。
origCause_Value 発信側のコールの終了の原因、符号なし整数。この原因は発信元デバイスへのコールが終了した理由を表します。 送信、転送などの場合、コールの終了の原因は発信側デバイスと終端デバイスとの相違の場合があります。 このため、各コールに関連付けられたその 2 つがフィールドがあります。 通常これらは同じです。
origMediaTransportAddress_IP 発信元のメディア接続の IP アドレス、符号なし整数。これは発信元からのメディア ストリームが接続された宛先 IP アドレスです。
origMediaTransportAddress_Port 発信元のメディア接続のポート、符号なし整数。これは発信元からのメディア ストリームが接続された宛先ポートです。
origMediaCap_payloadCapability 発信元が使用するコーデック タイプ、符号なし整数。このフィールドには、発信元がこのコール中に送信側で使用するコーデック タイプ(圧縮またはペイロード タイプ)が含まれています。 これは、受信側で使用するコーデック タイプと異なる場合があります。
origMediaCap_maxFramesPerPacket パケットあたりのデータのミリ秒数、符号なし整数。このフィールドには、このコールの発信元が宛先に送信するパケットあたりのデータのミリ秒数が含まれます。 実際のデータ サイズはデータを生成するために使用されるコーデック タイプによって異なります。
origMediaCap_g723BitRate G.723 で使用されるビット レート、符号なし整数。G.723 で使用されるビット レートを定義します。 ビット レート値は、 1 =5.3K ビット レートおよび 2 = 6.3K ビット レートの 2 つです。
lastRedirectDn このコールを最後にリダイレクトされた側の電話番号、25 文字までの文字列。このコールをリダイレクトされた最後のデバイスの電話番号です。 このフィールドは、電話会議、転送コールなど、リダイレクトされたコールにのみ表示されるフィールドです。
lastRedirectDnPartition このコールを最後にリダイレクトされた電話のパーティション、50 文字までの文字列。このコールをリダイレクトされた最後のデバイスのパーティションです。 このフィールドは、電話会議、転送コールなど、リダイレクトされたコールにのみ表示されるフィールドです。
destLegIdentifier コールの宛先レッグのコール ID、符号なし整数。これは、このコールの宛先レッグを追跡するために使用される固有識別子です。 これはクラスタ内で一義的です。
destNodeId コールの宛先が登録されているノードのノード ID符号なし整数。このコールの時点で 宛先デバイスが登録されている Cisco CallManager クラスタ内のノードです。
dest Span 宛先の SPAN またはノード、符号なし整数。コールがゲートウェイ経由で終了している場合は、このフィールドには宛先のポートまたは SPAN 番号が含まれています。 そうでない場合、このフィールドにはゼロ(0)が含まれます。
destIpAddr コールが配信された IP アドレス、符号なし整数。このフィールドには、コールを終了したデバイスのシグナリング接続の IP アドレスが含まれています。
destIpPort コールが配信された IP ポート、符号なし整数。このフィールドには、コールを終了したデバイスのシグナリング接続の IP ポートが含まれています。
originalCalledPartyNumber コール発信元から受信する宛先、25 文字までの文字列。このフィールドには、コールの発信元がダイヤルした数字に基づいて一元的に拡張された電話番号が含まれます。 コールが正常に完了する(つまり、転送されない)と、この電話番号は「finalCalledPartyNumber」と常に同じになります。 コールが転送された場合、このフィールドには、コールが転送される前の元の宛先番号が入ります。
originalCalledPartyNumberPartition 着信側のパーティション、50 文字までの文字列。このフィールドには、着信側に関連付けられているパーティションが含まれています。
finalCalledPartyNumber コールが配信された宛先、25 文字までの文字列。このフィールドには、コールが実際に展開された電話番号が含まれています。 コールが正常に完了する(つまり、転送されない)と、この電話番号は「foriginalCalledPartyNumber」と常に同じになります。 コールが転送された場合、このフィールドには、すべての転送が完了した後で、コールの最終宛先の電話番号が入ります。
finalCalledPartyNumberPartition コールの最終的な宛先に関連付けられたパーティション 50 文字までの文字列。このフィールドには、コールが実際に展開された宛先に関連付けられているパーティションが含まれています。 通常のコールでは、このフィールドは [originalCalledPartyNumberPartition」 と同じはずです。 コールが転送された場合、このフィールドには、すべての転送が完了した後で、コールの最終宛先のパーティションが入ります。
destCause_location 着信側の原因ロケーション値 、符号なし整数。これは、原因情報要素の ISDN ロケーション値です。
destCause_value 着信側のコールの終了の原因、符号なし整数。この原因は終了デバイスへのコールがなぜ終了したかを表します。 送信、転送などの場合、コールの終了の原因はコールの受信者とコールの発信者との相違の場合があります。 このため、各コールに関連付けられたその 2 つがフィールドがあります。 通常これらは同じです。 転送の対象であるビジーなデバイスへのコールの展開を試みる場合、コールが転送先に接続されても原因コードの「Busy」が戻されます。
destMediaTransportAddress_IP 宛先発信のメディア接続の IP アドレス、符号なし整数。これは宛先へのメディア ストリームが接続された発信元 IP アドレスです。
destMediaTransportAddress_Port 宛先発信のメディア接続のポート、符号なし整数。これは宛先へのメディア ストリームが接続された発信元 ポートです。
destMediaCap_payloadCapability 送信側の宛先が使用するコーデック タイプ、符号なし整数。このフィールドには、宛先がこのコール中に送信側で使用するコーデック タイプ(圧縮またはペイロード タイプ)が含まれています。 これは、受信側で使用するコーデック タイプと異なる場合があります。
destMediaCap_maxFramesPerPacket パケットあたりのデータのミリ秒数、符号なし整数。このフィールドには、このコールの宛先が発信元に送信するパケットあたりのデータのミリ秒数が含まれます。 実際のデータ サイズはデータを生成するために使用されるコーデック タイプによって異なります。
destMediaCap_g723BitRate G.723 で使用されるビット レート、符号なし整数。G.723 で使用されるビット レートを定義します。 ビット レート値は、 1 =5.3K ビット レートおよび 2 = 6.3K ビット レートの 2 つです。
接続日時 接続の日時、符号なし整数。これは、コールが発信デバイスと着信デバイス間で繋がった日時です。 値は協定世界時(UTC)値で、1970 年 1 月 1 日深夜(00:00:00)以降の秒数で表します。
dateTimeDisconnect 接続解除の日時、符号なし整数。これは、発信デバイスと着信デバイス間でコールの接続が解除された日時、または一度も接続されていなくても音量が小さくなってしまう場合の日時です。 値は協定世界時(UTC)値で、1970 年 1 月 1 日深夜(00:00:00)以降の秒数で表します。
期間 コール期間コールが接続されていた秒数です。 これは、接続の日時と接続解除の日時の差です。

CMR のフィールド定義

以下の表には、CMR(別名 Diagnostic CDR)のフィールドの定義が記載されています。

フィールド定義
フィールド 定義
cdrRecordType このレコーのタイプ、符号なし整数、この特定のレコードのタイプを指定します。 これは、CMR レコードに設定されます。
globalCallIdentifier このコールのグローバル コール識別子、グローバル コール識別子はどちらも符号なし整数である 2 個のフィールドから構成されます。 値は符号なし整数として扱われる必要があります。 2 つのフィールドは次のとおりです。 符号なし整数の GlobalCallID_CallID、符号なし整数 GlobalCallID_CallManagerID。これらは、コール全体に割り当てられるコール ID です。 すべてのレコードが同じグローバル コール識別子を持つ標準コールに関連付けられています。
nodeID Cisco CallManager ノード ID。このレコードが生成された Cisco CallManager クラスタ内のノード。
callIdentifier コール ID、符号なし整数。このレコードが属するコール レッグを識別するコール レッグの識別子です。
directoryNum このコールで使用する電話番号。この診断が収集されたデバイスの電話番号です。
directoryNumPartition 電話番号に関連付けられているパーティション。これは、このレコードの電話番号のパーティションです。
dateTimeStamp コールの終了の日時。これは、デバイスがオン フックになたおおよその時刻を表します。 この時間は、電話機が診断情報の要求に応答したときにレコードに記録されます。 これは time_t 値です。
numberPacketsSent 送信済みパケット数。この接続で送信を開始してからデバイスによって送信された RTP データ パケットの総数。 接続が「受信専用」モードに設定されている場合、この値はゼロです。
numberOctetsSent 相手側に送信したデータのオクテット数(バイト)。この接続で送信の開始以降に RTP データ パケットでこのデバイスで送信したペイロール オクテット(ヘッダーおよびパディングは除く)の総数。 接続が「受信専用」モードに設定されている場合、この値はゼロです。
numberPacketsReceived このコールの間に受信したデータ パケット数。この接続で受信を開始してからデバイスによって受信された RTP データ パケットの総数。 マルチキャスト コールの場合、この数には、異なるソースから受信されたパケットが含まれます。 接続が「送信専用」モードに設定されている場合、この値はゼロです。
numberOctetsReceived このコールの間に受信したデータのオクテット数(バイト)。この接続で受信の開始以降に RTP データ パケットでこのデバイスで受信したペイロール オクテット(ヘッダーおよびパディングは除く)の総数。 マルチキャスト コールの場合、この数には、異なるソースから受信されたパケットが含まれます。 接続が「送信専用」モードに設定されている場合、この値はゼロです。
numberPacketsLost この接続の間に失った RTP データ パケット数。受信の開始以降に失った RTP データ パケットの総数。 この番号は、実際に受信したパケット数よりも少ない予想パケット数として定義されます。この場合、受信パケット数には遅延または重複したパケットが含まれます。 したがって、遅れて到達したパケットは失ったパケットとしてカウントされず、重複があった場合にこのカウンターが負の数になることがあります。 予想されるパケットの数は最後に受信した連番に定義し、次の定義では最初に受信した連番より少なくします。 接続が「送信専用」モードに設定されている場合、この値はゼロです。 (詳細については、『RFC 1889』を参照してください)。
ジッター この接続中の Inter-Arrival ジッター。RTP データ パケットの Inter-Arrival 時間(到着間隔)の統計的分散の予測値で ミリ秒で測定され、符号なし整数として表示されます。 到着間ジッター J は、パケットのペアの送信側と比較された受信側のパケット帯域幅の差 D の平均偏差(平滑化された絶対値)として定義されます。 詳細な計算のアルゴリズムは『RFC 1889』にあります。 接続が「送信専用」モードに設定されている場合、この値はゼロです。
遅延 この接続中に遅延が発生した。値はミリ秒で表記されたネットワーク遅延の推定値です。 これは、RTP Control Protocol (RTCP)メッセージの送信者によって示されるネットワーク タイム プロトコル(NTP)のタイムスタンプと受信者の NTP のタイムスタンプの差の平均値で、これらのメッセージが受信されたときに測定されます。 平均は、すべての推定値を合計してから受信した RTCP メッセージの数で割って求めます。 (詳細については 『Request For Comments (RFC) 188』を参照してください)。

コールタイプごとに記録されるコール レコード

2 者間の各通常のコールは 1 つの CDR エンド コール レコードにログ記録されます。 各エンド コール レコードには上で示したすべてのフィールドが含まれていますが、使用できないフィールドもあります。 フィールドを使用しない場合、ASCII 文字列フィールドは空白、数値フィールドは「0」です。 補足サービスがコールと関連していると、さらに多くのエンド コール レコードが書き込まれることがあります。

CDR エンド コール レコードに加えて、エンド ポイントごとに最大 1 つの CMR レコードがコールに関わってきます。 Cisco IP Phone を使用している 2 者間の通常のコールでは、2 つの CMR レコード、つまり コールの発信元で 1 つ、コールの宛先で 1 つが書き込まれます。

この項では、システムでさまざまなコール タイプ用に作成されるレコードについて説明します。

通常のコール(Cisco IP Phone 間)

通常のコールでは、コールごとに 3 レコードをロギングします。 これらは EndCall と 2 つの診断レコード(各エンドポイントに 1 つ)です。 EndCall レコードでは、すべてのフィールドに有効な情報が含まれている可能性があります。 期間は「CdrLogCallsWithZeroDurationFlag」フラグが有効(真に設定)な場合以外は、ゼロ以外は常になります。 「originalCalledPartyNumber」フィールドは「finalCalledPartyNumber」フィールドと同じ電話番号が含まれています。

放棄呼

ゼロの期間でのコールのロギングは任意選択です。 通常、これらのレコードはロギングされません。 ゼロの期間のコールのロギングを有効にするには、次の点に注意する必要があります。

  • 電話機がオフフックになったり、オンフックに戻ったりするなど、コールが放棄された場合、各種のフィールドにデータは含まれません。 この場合、「originalCalledPartyNumber 」、「finalCalledPartyNumber」、これらに関連するパーティション、「destIpAddr」、および 「dateTimeConnect」フィールドが空白になります。 接続されていないすべてのコールでは「期間」はゼロ秒です。 コールが放棄されると、原因コードは「0」になります。

  • 電話番号をダイヤルし、接続する前にコールが放棄される場合、「First Dest」フィールドおよび「Final Dest」フィールド、およびこれに関連付けられているパーティションに、コールが展開された電話番号とパーティションが含まれています。 「Dest IP」フィールドは空白で、期間はゼロになります。

転送またはリダイレクトされたコール

転送されたコールのコール レコードは「originalCalledPartyNumber」フィールドおよび「originalCalledPartyNumberPartition」フィールドを除いて、通常のコールのものと同じです。 これらのフィールドには、元の発信者が最初にダイヤルした宛先の電話番号とパーティションが格納されます。 コールが転送された場合、「finalCalledPartyNumber」フィールドおよび「finalCalledpartyNumberPartition」フィールドは異なり、コールの最終宛先の電話番号およびパーティションが含まれています。 また、コールが転送された場合、「lastRedirectDn」フィールドおよび「lastRedirectDnPartition」フィールドには、このコールを最後に転送またはリダイレクトした電話の電話番号およびパーティションが含まれています。

相手先が話し中または不正なコール

これらのコールは、すべての関連するフィールドにデータを含む通常のコールとしてロギングされます。 「Called Party Cause」 フィールドはコールがなぜ接続されなかったかを示す原因コードを含み、「Called Party IP」および「Date/Time Connect」フィールドは空白になります。 発信側がコールを放棄した場合、原因は、「NO_ERROR」(0)です。 期間は常にゼロ秒となります。 これらのコールは、「CdrLogCallsWithZeroDurationFlag」が有効な場合、記録されません。

コール タイプごとに記録されるコール管理レコード

2 台の Cisco IP Phone 間の各通常コールでは、2 つの CMR レコードがロギングされします。 各コール CMR レコードには、上に示したすべてのフィールドが含まれています。 補足サービスがコールと関連していると、複数のレコードが書き込まれることがあります。 この項では、システムでさまざまなコール タイプ用に作成される診断レコードについて説明します。

通常のコール

通常のコールでは、コールごとに 2 つの CMR レコード、つまりコールに関連した電話機ごとに 1 つのレコードがロギングされます。 現在、Cisco IP Phone および MGCP ゲートウェイだけが診断情報の要求に応答できます。 すべてのフィールドが有効情報を含んでいます。

放棄呼

電話機がオフフックになったり、オンフックに戻ったりするなど、コールが放棄された場合、ストリーミング データに関係するすべてのフィールドは空白(ゼロ)です。 これは、ストリーミングの接続が確立されていないためで、そのためにデータは転送されていませんでした。 「CdrLogCallsWithZeroDurationFlag」が無効の場合は、空白のフィールドのあるレコードはロギングできません。

転送されたコール

転送されたコールのコール レコードは通常のコールのものと同じです。

相手先が話し中または不正なコール

通常は、実際に接続されたコールを表すレコードだけが記録されます。 不正な宛先のコールのために、「CdrLogCallsWithZeroDurationFlag」を有効にする必要があります。 これが有効になっていると、ユーザが再びオフフックになったあとオン フックに戻った場合などすべてのコールがロギングされます。

これらのコールがロギングされると、すべての関連するフィールドにデータを含む通常のコールとしてロギングされます。 コールが宛先には接続されていないため、コールごとにのレコードは 1 件だけです。 このレコードは、コールの発信元のものです。

コーデックタイプ (圧縮 / ペイロードのタイプ)

次の表に、コーデック タイプの値と説明を示します。

コーデックの説明
コーデック 説明
1 非標準
2 G711A-law 64k
3 G711A-law 56k
4 G711?-law 64k
5 G711?-law 56K
6 G722 64k
7 G722 56k
8 G722 48k
9 G7231
10 G728
11 G729
12 G729AnnexA
13 Is11172AudioCap
14 Is13818AudioCap
15 G729AnnexB
32 Data 64k
33 Data 56k
80 GSM
81 ActiveVoice
82 G726_32K
83 G726_24K
84 G726_16K

原因コード

次の表では、[Cause] フィールドに表示される可能性のある原因コードのリストについて説明します。

原因コードの説明
原因コード 説明
0 エラーなし
1 Unallocated (unassigned) number
2 指定された中継ネットワークへのルートなし(国別使用)
3 宛先への経路がない
4 特殊な情報トーンを送信する
5 トランク プレフィックスのかけ間違い(国際使用)
6 チャネルが受け入れ不可能
7 コールが確立されたチャネル内で与えられ、配信されている
8 プリエンプション
9 プリエンプション - 回路が再利用に予約されている
16 正常なコール クリア
17 ユーザ ビジー
18 ユーザ応答なし
19 ユーザからの応答なし(ユーザ アラート)
20 加入者不在
21 コール拒否
22 番号変更
26 非選択ユーザのクリア
27 宛先異常
28 無効な番号形式(アドレスが不完全)
29 ファシリティ拒否
30 ステータス問い合わせへの応答
31 正常、詳細不明
34 利用可能な回路/チャネルなし
38 ネットワーク故障
39 永久フレームモード接続がアウト オブ サービス
40 固定フレーム モード接続が動作中
41 一時的な障害
42 交換機器の輻輳
43 アクセス情報が廃棄された
44 リクエストされた回路/チャネルの利用不可
46 先のコールがブロックされた
47 リソースを使用できません(未指定)。
49 QoS が利用できない
50 要求されたファシリティが未登録
53 サービス運用違反
54 着信コールが妨害された
55 非公開ユーザ グループ(CUG)内で着信コール除外
57 ベアラ機能が無許可
58 ベアラ機能が現在使用不能
62 指定された発信アクセス情報と加入者クラスが矛盾している
63 サービスまたはオプションが利用できない、未指定
65 ベアラ機能が未実装
66 チャネル タイプが未実装
69 要求されたファシリティが未実装
70 制限されたデジタル情報ベアラ機能しか利用できない(国際使用)
79 サービスまたはオプションが実装されていない、未指定
81 不正なコール参照値
82 特定されたチャネルが存在しない
83 サスペンドされたコールがあるが、このコール ID がない
84 コール ID が使用中
85 サスペンドされたコールはない
86 要求されたコール ID を持つコールがクリアされている
87 ユーザが非公開ユーザ グループ(CUG)のメンバではありません。
88 互換性のない宛先
90 宛先番号がなく、DC がサブスクライブされていない
91 無効な中継ネットワーク(国際使用)
95 無効なメッセージ、詳細不明
96 必須の情報要素が欠如
97 メッセージ タイプが存在しないか実装されない
98 メッセージにコール状態との互換性がないか、またはメッセージ タイプが存在しないか実装されていない
99 情報要素またはパラメータが存在しないか実装されていない
100 無効な情報要素コンテンツ
101 メッセージにコール状態との互換性がない
102 タイマーが期限切れとなりコールが終了した、エラーから回復するために回復ルーチンが実行された
103 パラメータが存在しないか実装されていない:渡された(国際使用)
110 認識されないパラメータを持つメッセージが破棄された
111 プロトコル エラー、詳細不明
126 コール分割 これは Cisco 独自のコードです。 これは、コールが分割されて終了したため、転送中にコールが終了した場合に適用されます(転送された最後のコールの一部ではありません)。 これは、どのコールが転送動作の一部として終了したかを調べるのに役立ちます。
127 インターワーキング、未特定

アラーム

アラームは、 CDR または診断データを有効にすると発行され、システムはデータベースにデータを書き込めません。

Unable to write CDR data. ((Alarm # 1711 - Major Alarm)

システムはデータベースを開こうとしますが、成功しません。 考えられる原因には次のものがあります。

  • Cisco CallManager にデータベースへの書き込みのためにファイルを開く十分な権限がありません。 Cisco CallManager に書き込み権限が許可されていることを確認してください。

  • パスは設定されないか、データベース サーバが動作していません。

Cisco Technical Assistance Center (TAC) への連絡

自分自身でトラブルシューティングで解決できない問題がある場合は、TAC にサポートを依頼してください。 TAC に連絡する前に、次の情報を用意してください。

  • Cisco CallManager の詳細

  • トポロジ

  • SDI および SDL トレースなど、トラブルシューティングで実行したトレースおよびログ、

  • WINNT\system32 directory and the Cisco CallManager trace のサブディレクトリにある Stackwalk.txt ファイル。

  • Cisco IOS ゲートウェイ上の sh-tech (使用可能な場合)

  • Cisco CallManager 上の sh tech

  • この問題が Cisco IOS ゲートウェイを経由したコールで発生している場合は、次の資料も提供してください。

    • debug voice ccapi inout

    • debug isdn q931

    • (AS5300 のみ)sh vfc xboard

    • (AS5300 のみ)sh vfc x version dspware

    • (AS5300 のみ)sh vfc x version vcware


関連情報


Document ID: 30266