Cisco Unified Communications Manager トラブルシューティング ガイド Release 6.0(1)

トポロジの例

Cluster 1 および Cluster 2 という 2 つのクラスタがあります。Cluster 1 には Unified CM3 および Unified CM4 という 2 つの Cisco Unified Communications Manager があり、Cluster 2 には Unified CM1 および Unified CM2 という 2 つの Cisco Unified Communications Manager があります。

このケース スタディのトレースは、Cluster 2 にある Unified CM1 から収集されたものです（図B-1 を参照）。Cluster 2 にある 2 台の Cisco Unified IP Phone がコール フローのベースです。これら 2 台の Cisco Unified IP Phone の IP アドレスは、それぞれ 172.16.70.230（電話番号 1000）と 172.16.70.231（電話番号 1001）です。

図B-1 Cisco IP Phone と Cisco IP Phone 間のクラスタ内コールのトポロジの例

Cisco Unified IP Phone の初期化プロセス

Cisco Unified IP Phone の初期化（ブート アップ）プロセスの詳細な手順を次に示します。

手順

ステップ 1 DHCP サーバで適切なオプション（Option 066、Option 150 など）が設定されていれば、Cisco Unified IP Phone は初期化時に DHCP サーバに対して要求を送信し、IP アドレス、Domain Name System（DNS; ドメイン ネーム システム）サーバのアドレス、および TFTP サーバの名前またはアドレスを取得します。また、DHCP サーバで該当するオプション（Option 003）が設定されている場合は、デフォルト ゲートウェイのアドレスも取得します。

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

ステップ 3 DHCP 応答に TFTP サーバ名が含まれていない場合、Cisco IP Phone はデフォルトのサーバ名を使用します。

ステップ 4 設定ファイル（.cnf）は TFTP サーバから取得されます。すべての .cnf ファイルには、SEP<MAC アドレス>.cnf という名前が付いています。この電話機を初めて Cisco Unified Communications Manager に登録する場合は、デフォルト ファイルの SEPdefault.cnf が Cisco Unified IP Phone にダウンロードされます。このケース スタディでは、1 台目の Cisco Unified IP Phone は IP アドレス 172.16.70.230（MAC アドレスは SEP0010EB001720）、2 台目の Cisco Unified IP Phone は IP アドレス 172.16.70.231（MAC アドレスは SEP003094C26105）をそれぞれ使用します。

ステップ 5 すべての .cnf ファイルには、プライマリおよびセカンダリの Cisco Unified Communications Manager の IP アドレスが含まれています。Cisco Unified IP Phone は、この IP アドレスを使用してプライマリ Cisco Unified Communications Manager に接続して登録します。

ステップ 6 Cisco Unified IP Phone が Cisco Unified Communications Manager に接続して登録すると、Cisco Unified Communications Manager は、使用する実行ファイルのバージョン（ロード ID と呼ばれる）をその Cisco Unified IP Phone に通知します。指定されたバージョンが Cisco Unified IP Phone 上の実行ファイルのバージョンと一致しない場合、Cisco Unified IP Phone は新しい実行ファイルのバージョンを TFTP サーバに要求し、自動的にリセットします。

Cisco Unified Communications Manager の初期化プロセス

この項では、Unified CM1（IP アドレス 172.16.70.228 で識別される）から取り込んだトレースを使用して、Cisco Unified Communications Manager の初期化プロセスについて説明します。前述のように、SDI トレースは、エンドポイント間で送信されたすべてのパケットに関する詳細情報を提供するので、非常に効果的なトラブルシューティング ツールです。

この項では、Cisco Unified Communications Manager の初期化時に発生するイベントについて説明します。トレースの見方を理解していれば、Cisco Unified Communications Manager の各プロセスのトラブルシューティング、およびそれらのプロセスがサービス（会議、転送など）に及ぼす影響のトラブルシューティングを適切に行うことができます。

次のメッセージは、Cisco Unified Communications Manager SDI トレース ユーティリティから出力され、Cisco Unified Communications Manager の 1 つ（このケース スタディでは Unified CM1）に対する初期化プロセスを示しています。

• 最初のメッセージは、Cisco Unified Communications Manager が自分の初期化プロセスを開始したことを示しています。

• 2 番目のメッセージは、Cisco Unified Communications Manager がデフォルト データベース（このケース スタディではプライマリ データベースまたはパブリッシャ データベース）の値を読み取ったことを示しています。

• 3 番目のメッセージは、Cisco Unified Communications Manager が TCP ポート 8002 で各種メッセージを受信したことを示しています。

• 4 番目のメッセージは、それらのメッセージを受信した後に、Cisco Unified Communications Manager が 2 つ目の Cisco Unified Communications Manager（Unified CM2（172.16.70.229））を自分のリストに加えたことを示しています。

• 5 番目のメッセージは、Cisco Unified Communications Manager が起動し、Cisco Unified Communications Manager バージョン 3.1(1) を実行していることを示しています。

自己起動プロセス

Cisco Unified Communications Manager は、稼働状態になると、その内部で他のプロセスをいくつか起動します。それらのプロセスには、MulticastPoint Manager、UnicastBridge Manager、番号分析、ルート リストなどがあります。これらのプロセスの実行中に出力されるメッセージは、Cisco Unified Communications Manager の機能に関連する問題のトラブルシューティングに非常に役立ちます。

たとえば、ルート リストが機能を停止して使用不可になっているとします。この問題のトラブルシューティングを行うには、これらのトレースを監視して、Cisco Unified Communications Manager が RoutePlanManager をすでに起動したか、および RouteLists のロードを試行しているかを確認します。次に示す設定の例は、RouteListName=''ipwan'' および RouteGroupName=''ipwan'' がロードおよび起動していることを示しています。

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

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

次のトレースでは、Cisco Unified Communications Manager の Device Manager が 2 つのデバイスを静的に初期化しています。IP アドレス 172.17.70.226 のデバイスはゲートキーパーを表し、IP アドレス 172.17.70.245 のデバイスは異なるクラスタにある別の Cisco Unified Communications Manager を取得します。その Cisco Unified Communications Manager は、H.323 ゲートウェイとしてこの Cisco Unified Communications Manager に登録されます。

Cisco Unified Communications Manager の登録プロセス

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

次のトレースでは、Cisco Unified Communications Manager が登録のための新しい接続を受信しています。登録するデバイスは、MTP_nsa-cm1（Unified CM1 上の MTP サービス）および CFB_nsa-cm1（Unified CM1 上の会議ブリッジ サービス）で構成されます。これらは Cisco Unified Communications Manager で動作しているソフトウェア サービスですが、内部的には異なる外部サービスとして扱われるため、TCPHandle、ソケット番号、ポート番号、およびデバイス名が割り当てられます。

Cisco Unified Communications Manager の KeepAlive プロセス

ステーション、デバイス、またはサービスと Cisco Unified Communications Manager は、相互間の通信チャネルに関する情報を保持するために次のメッセージを使用します。このメッセージは、Cisco Unified Communications Manager とステーション間の通信リンクがアクティブ状態を維持するためのキープアライブ シーケンスを開始します。次のメッセージは、Cisco Unified Communications Manager とステーションのどちらからでも発信できます。

次のトレースに含まれるメッセージは、Cisco Unified Communications Manager とステーション間の通信リンクがアクティブであることを示すキープアライブ シーケンスを表しています。これらのメッセージも、Cisco Unified Communications Manager とステーションのどちらからでも発信できます。

Cisco Unified Communications Manager のクラスタ内コール フローのトレース

この項の SDI トレースは、クラスタ内コール フローの詳細を示しています。コール フローの Cisco Unified IP Phone は、電話番号（dn）、tcpHandle、および IP アドレスで識別できます。Cluster 2 に配置された Cisco Unified IP Phone（dn：1001、tcpHandle：0x4fbbc30、IP アドレス：172.16.70.231）は、同一クラスタ内の別の Cisco Unified IP Phone（dn：1000、tcpHandle：0x4fbb150、IP アドレス：172.16.70.230）にコールを発信します。TCP ハンドル値、タイム スタンプ、またはデバイスの名前を調べることで、デバイスをトレース上で追跡できます。デバイスをリブートするかオフラインにするまで、デバイスの TCP ハンドル値は変わりません。

次のトレースは、Cisco Unified IP Phone（1001）がオフフックになっていることを示しています。下記のトレースは、一意のメッセージ、TCP ハンドル、および着信側の番号を示しています。これらは Cisco Unified IP Phone に表示されます。この時点では、まだユーザが番号をダイヤルしていないので、発信側の番号は表示されていません。次の情報は、Cisco Unified IP Phone と Cisco Unified Communications Manager 間の Skinny Station メッセージの形式で表示されます。

次のトレースは、Cisco Unified Communications Manager から Cisco Unified IP Phone に発信された Skinny Station メッセージを示しています。最初のメッセージは、発信側の Cisco Unified IP Phone のランプをオンにします。

Cisco Unified Communications Manager は、stationOutputCallState メッセージを使用して、特定のコールに関する情報をステーションに通知します。

Cisco Unified Communications Manager は、stationOutputDisplayPromptStatus メッセージを使用して、コールに関するプロンプト メッセージを Cisco Unified IP Phone に表示します。

Cisco Unified Communications Manager は、stationOutputSelectSoftKey メッセージを使用して、Skinny Station で特定のソフトキーのセットを選択します。

Cisco Unified Communications Manager は、次のメッセージを使用して、表示用の正確な回線コンテキストについて Skinny Station に指示します。

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

次のデバッグ メッセージは、Cisco Unified Communications Manager が発信側の Cisco Unified IP Phone に内部発信音を鳴らしていることを示しています。

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

Cisco Unified Communications Manager は、一致していると判別できるだけの番号を受信すると、番号分析の結果をテーブル形式で表示します。一致するものがすでに見つかっているので、Cisco Unified Communications Manager は、それ以降に電話機で押された番号をすべて無視します。

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

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

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

Cisco Unified Communications Manager が発信側の Cisco Unified IP Phone にも同様の情報を提供していることに注意してください。ここでも、Cisco Unified IP Phone は tcpHandle によって識別されます。

次のトレースでは、Cisco Unified Communications Manager がアラート音または呼び出し音を発信側の Cisco Unified IP Phone で鳴らし、接続が確立されたことを通知しています。

この時点で、着信側の Cisco Unified IP Phone はオフフックになるので、Cisco Unified Communications Manager は発信側での呼び出し音を停止します。

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

（注） 通常、この値は 30 ミリ秒に設定されます。このケース スタディでは、20 ミリ秒に設定されます。

同様に、Cisco Unified Communications Manager は着信側（1000）に情報を提供します。

Cisco Unified Communications Manager は、RTP ストリーム用のオープン チャネルを確立するために、着信側から確認応答メッセージを受信しました。また、着信側の IP アドレスも受信しました。このメッセージにより、Skinny Station に関する 2 種類の情報が Cisco Unified Communications Manager に通知されます。1 つは、オープン アクションのステータスです。もう 1 つは、リモート エンドへの伝送に使用する受信ポートのアドレスと番号です。RTP ストリームのトランスミッタ（発信側）の IP アドレスは ipAddr で、PortNumber は RTP ストリーム トランスミッタ（発信側）の IP ポート番号です。

Cisco Unified Communications Manager は、次のメッセージを使用して、指定のリモート Cisco Unified IP Phone の IP アドレスとポート番号に音声およびビデオ ストリームの伝送を開始するようにステーションに指示しています。

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

最後に、発信側の Cisco IP Phone がオンフックになります。そのため、Skinny Station と Cisco Unified Communications Manager 間のすべての制御メッセージ、および Skinny Station 間の RTP ストリームが終了します。

トポロジの例

このケース スタディでは、次に示すトポロジの例を使用します。2 つのクラスタがあり、各クラスタには 2 つの Cisco Unified Communications Manager があります。また、Cisco IOS Gateway と Cisco IOS Gatekeeper も配置されています。

クラスタ間 H.323 通信

Cluster 1 の Cisco IP Phone が Cluster 2 の Cisco Unified IP Phone にコールを発信します。クラスタ間 Cisco Unified Communications Manager 通信は、H.323 バージョン 2 プロトコルを使用して行われます。Cisco IOS Gatekeeper もアドミッション制御に使用されます。

Cisco Unified IP Phone は Skinny Station プロトコルを使用して Cisco Unified Communications Manager に接続でき、Cisco Unified Communications Manager は H.323 Registration, Admission, and Status（RAS）プロトコルを使用して Cisco IOS Gatekeeper に接続できます。admission request（ARQ; アドミッション要求）メッセージが Cisco IOS Gatekeeper に送信され、この Gatekeeper は H.323 バージョン 2 プロトコルを使用してクラスタ間コールが発信できることを確認した後、admission confirmed（ACF; アドミッション確認）メッセージを送信します。この処理が実行された後、RTP プロトコルを使用して、異なるクラスタにある Cisco Unified IP Phone 間に音声パスが作成されます。

コール フローのトレース

この項では、CCM000000000 ファイルに取り込んだ SDI トレースの例を使用して、コール フローについて説明します。このケース スタディで取り上げるトレースでは、コール フロー自体に焦点を絞っています。

このコール フローでは、Cluster 2 に配置された Cisco Unified IP Phone（2002）が、Cluster 1 に配置された Cisco Unified IP Phone（1001）にコールを発信します。TCP ハンドル値、タイム スタンプ、またはデバイスの名前を調べることで、デバイスをトレース上で追跡できます。デバイスをリブートするかオフラインにするまで、デバイスの TCP ハンドル値は変わりません。

次のトレースでは、Cisco Unified IP Phone（2002）がオフフックになりました。このトレースは、一意のメッセージ、TCP ハンドル、および発信側の番号を示しています。これらは Cisco Unified IP Phone に表示されます。次のデバッグ出力は、着信側の番号（1001）、H.225 接続、および H.245 確認メッセージを示しています。コーデック タイプは G.711 mu-law です。

次のトレースは、発信側と着信側の番号を示しています。これらの番号は IP アドレスおよび 16 進数値に関連付けられています。

次のトレースは、Cisco IP Phone（2002）のパケット サイズと MAC アドレスを示しています。このトレースの後に接続解除メッセージが続き、その後にオンフック メッセージが続きます。

コール フローの失敗

この項では、SDI トレースを確認しながら、クラスタ間コール フローの失敗について説明します。次のトレースでは、Cisco Unified IP Phone（1001）はオフフックになります。TCP ハンドルが Cisco Unified IP Phone に割り当てられます。

次のトレースでは、ユーザが着信側の Cisco Unified IP Phone の番号（2000）をダイヤルし、番号分析プロセスが番号を照合しようとしています。

これで番号分析が完了しました。次のトレースは、その結果を示しています。次の
PotentialMatches=NoPotentialMatchesExist 参照は、Cisco Unified Communications Manager がこの電話番号を照合できないことを示しています。この点に注意してください。最後に、リオーダー音が発信側（1001）に送信され、その後にオンフック メッセージが続きます。