- はじめに
- CUCM でコールが失敗する問題の切り分けステップ
- Step 1. 問題に関する情報を収集する
- Step 2. コールフローを特定する
- Step 3. 問題となるノードを特定する
- Step 4. 原因を特定する
- (参考) Voice Gateway におけるコールが切断される問題のトラブルシューティング
- サービスリクエストのオープン
- 参考リンク
はじめに
本 ドキュメントでは、CUCM (Cisco Unified Communications Manager) に登録された IP Phone から発信されたコールや、Voice Gateway などの機器から CUCM に対して発信されたコールが失敗する問題のトラブルシューティング手法を紹介します。コールが失敗する例としては、宛先の電話番号をダイヤルしてもビジー トーンが返信されて宛先と通話できない、宛先が応答して通話状態になった直後に切断される、通話中にしばらくすると切断される、などがあります。これらの 問題をどのようなステップを踏んで解決するかについて説明します。
TAC エンジニアもコールが失敗する問題については同様の流れで解析を行っているため、サービスリクエストをオープンする場合は、解析に必要な情報を事前に収集しておくことが迅速な問題解決につながります。
本ドキュメントでは、現在シグナリングプロトコルとして SIP (Session Initiation Protocol) が主流となっていることから、SIP を中心に記載しています。
CUCM でコールが失敗する問題の切り分けステップ
CUCM でコールが失敗する問題のトラブルシューティングは、大きく分けて下記の 4 つのステップに分けることができます。Step 4. の原因特定は TAC エンジニアの解析が必要になる場合がありますが、Step 1. から Step 3. までは公開されている情報やツールで行うことができます。
Step 1. 問題に関する情報を収集する
コー ルが失敗する問題に関わらず、問題が発生した場合はそれに関する情報を正しく収集することが必須となります。コールが失敗する問題については下記のような 情報が必要となります。問題に関するこれらの情報を収集することは、Step 2. のコールフローを特定するための重要な作業となります。
- ネットワークトポロジー (各ノードのホスト名や IP アドレス情報を含む)
- 失敗したコールの正確な発信時刻、切断時刻
- 失敗したコールの発信元番号、宛先番号、転送元番号（転送された場合）
- どのようにしてコールが失敗するか (ビジートーンが聞こえる、無音になる、通話中に切断される、等)。IP Phone のディスプレイ上に何か表示されていないか確認
- いつから発生するようになったか。何か設定変更などがあったかどうか
- 全てのコールで発生するか、それとも特定の宛先や発信元のみで事象が発生するか
問題に関する情報を収集したら Step 2 へ進みます。
Step 2. コールフローを特定する
Step 1. で収集した情報を使って問題となるコールフローを特定します。問題となるコールフローを特定するためには、シグナリングプロトコルの解析が必要となります。そのために、下記のツールを用いて CUCM で送受信されるシグナリングプロトコルを解析します。
1). CUCM のトレースログを TranslatorX で解析する
2). CUCM のトレースログを RTMT Session Trace で解析する
3). ネットワークキャプチャを Wireshark で解析する
1). CUCM のトレースログを TranslatorX で解析する
TranslatorX は CUCM の Cisco CallManager トレースログをデコードし、CUCM で送受信される SIP や H.323 などのシグナリングプロトコルを表示するツールです。TAC エンジニアも主にこのツールを使って CallManager トレースログの一次解析を行っています。
Cisco CallManager トレースログの収集方法と TranslatorX の詳細な使い方については下記を参照してください。
事 前に CUCM で CDR (Call Detail Record) が有効になっている場合は、TranslatorX のコールリスト機能が使えますので Cisco CallManager トレースログを読み込ませると、コールの一覧が表示されますので、Step 1. で確認したコールがないか確認します（サービスパラメータ "CDR Log Calls with Zero Duration Flag" がデフォルトの False の場合は通信中にならないとコールリストには表示されません）。コールリストに該当のコールがあった場合はクリックしてそのコールのみ表示します。
CUCM で CDR が有効になっていない場合は、TranslatorX で表示された情報から、Step 1. で確認した発信時刻、発信元の IP アドレス、発信元番号、宛先番号などの情報を用いて、発信時のメッセージ (SIP: To-tag なしの INVITE, H.225: SETUP) を探します。発信時のメッセージ上で SIP の場合は Call-ID, H.225 の場合は Call Reference でフィルタすることによって、該当のコールの一連のメッセージが表示されます。
コー ルが CUCM ではなく、Voice Gateway など他のノードで失敗している場合は CUCM が IP Phone などから受信する SIP INVITE や H.225 SETUP だけでなく、CUCM から Voice Gateway などに発信する INVITE や SETUP についても確認します。CUCM は SIP B2BUA (Back-to-Back User Agent) として動作しているため、CUCM が受信する INVITE と CUCM が送信する INVITE の Call-ID は異なる文字列が用いられることに注意してください。
最終的に CUCM を中心として下記のように SIP の場合は INVITE から始まってエラーレスポンスもしくは BYE で終了するコールフローを確認できるようにします。下記のコールは成功している例ですが、失敗する場合は CUCM か Voice Gateway などからエラーレスポンスが返信されている場合があります。もし、特定の宛先や送信元からのみ問題が発生する場合は、比較のため、問題があるコールフロー だけでなく、問題がない場合のコールフローについても確認することが望ましいです。
2). CUCM のトレースログを RTMT Session Trace で解析する
RTMT (Real-Time Monitoring Tool) の Session Trace を使ってコールフローを特定する方法を紹介します。この機能は SIP 限定となりますが、Cisco CallManager トレースログをローカル PC にダウンロードすることなく直接 RTMT が読み込んでコールフローを表示するため、現地でリアルタイムに調査する場合に適しています。
使い方の詳細は下記のドキュメントを参照してください。
- RTMT Session Trace による SIP コールの確認方法
- Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 10.0(1)
Session Trace でも TranslatorX と同様に Step 1. で収集した発信時刻や宛先番号などの情報から問題となるコールのコールフローを特定することが目的となります。
3). ネットワークキャプチャを Wireshark で解析する
ネットワークキャプチャを取得し、Wireshark を使ってコールフローを特定する方法を紹介します。ネットワークキャプチャは、CUCM 上、スイッチ上、ルータ上で取得することができます。それぞれの取得方法は以下の通りです。
- [CUCM 上で取得]: CUCM アプライアンス モデルでのパケット キャプチャ
- [スイッチ上で取得]: Catalyst スイッチド ポート アナライザ（SPAN）の設定例
- [ルータ上で取得]: ルータ上でパケットキャプチャを取得する方法 (IP Traffic Export)
ネッ トワークキャプチャを取得したら、Wireshark でキャプチャファイルを開きます。[Telephony] タブから [VoIP Calls] を選択するとコールの一覧が表示されますので、Step 1. で確認した情報から問題となるコールを選択し、[Flow] をクリックすると該当のコールフローが表示されます。CUCM が IP Phone から受信したコールと Voice Gateway などへ発信したコールは別々に表示されるので場合によっては 2 つ選択して [Flow] をクリックします。結果として、下記のようなコールフローが表示されます。
Wireshark の操作についての詳細な手順は下記のドキュメントもご参照ください。
問題となるコールフローを特定したら Step 3 へ進みます。
もし、発信元や宛先などの条件の変化によって問題が発生しないようであれば、比較のため、問題が発生しない場合のコールフローについても確認しておくことを推奨します。
Step 3. 問題となるノードを特定する
Step 2. で問題となるコールフローを特定したら、どのノードがエラーレスポンスなどを生成して切断しているかを確認し、問題となるノードを特定します。SIP でコールが失敗する場合、INVITE にエラーレスポンスが返信されるか、CANCEL でコールがキャンセルされるか、一旦通話中状態となって BYE で切断されるかのいずれかとなります。設定などにより、エラーレスポンスが返らずに 183 Session Progress メッセージで不在ガイダンスやビジートーンなどが音として流れる場合もあります。
以下に、IP Phone が CUCM と Voice Gateway 経由で外線発信する場合について、コールが失敗するフローのいくつかの例を紹介します。
- CUCM がエラーを検出してコールが失敗する場合
- Voice Gateway がエラーを検出してコールが失敗する場合
- PSTN 側がエラーを検出してコールが失敗する場合
- PSTN 側がエラーを検出して、エラーメッセージを返さずに音声メッセージを流す場合
- 通話中に CUCM がエラーを検出して CUCM が切断した場合
問題となるノードを特定したら、Step 4. に進みます。
Step 4. 原因を特定する
Step 3. で問題となるノードを特定したら、最後になぜそのノードで切断されたかについて原因を特定していきます。
切断理由を示す理由コード
CUCM や Voice Gateway では、SIP や H.323 や ISDN でコールが切断された場合には切断の理由を示すコード (理由コード: Cause Codes) を生成し、CDR やシグナリングメッセージに表示します。理由コードとして、CUCM や Voice Gateway は、ITU 勧告 Q.850 を参照し、独自のコードを追加しています。
以下に、CUCM でよく見られる理由コードの一覧の抜粋と想定される原因を記載します。コールが切断される問題が発生した場合は、理由コードを確認して原因を推測し、構成や設定を再確認してください。
| 理由コード | Description | 想定される原因 |
| 1 | Unallocated (unassigned) number |
ルートパターンにない番号に発信した。 登録されていない番号に発信した。 一時的に未登録状態の番号に発信した。 |
| 16 | Normal call clearing | 正常切断。 |
| 17 | User busy | ビジー状態の相手に発信した。 |
| 21 | Call rejected | 何らかの理由でコールが拒否された。 |
| 41 | Temporary failure |
一時的な内部エラーが発生した。 通話中に IP Phone と CUCM の接続が切れた。 |
|
47 |
Resource unavailable, unspecified |
コーデックのネゴシエーションに失敗した。 メディアリソースを確保できなかった。 |
| 125 | Out of bandwidth (Cisco specific) |
ロケーション設定の帯域が不足していた。 |
CUCM の理由コードの一覧については下記のドキュメントを参照してください。
Voice Gateway の理由コードの一覧については下記のドキュメントを参照してください。
- VoIP Cause Codes and Debug Values
- SIP and H.323 Internal Cause Codes
- Understanding debug isdn q931 Disconnect Cause Codes
Voice Gateway が NTT の ISDN に接続している場合は NTT技術参考資料が参考になります。ISDN の場合、理由コードと合わせて生成源についても確認してください。
理由コードの確認方法
SIP メッセージや CDR などから理由コードを確認する方法を紹介します。
- SIP メッセージの Reason ヘッダによる理由コードの確認
TranslatorX、 Session Trace、パケットキャプチャなどにより、切断したノードが送信した SIP メッセージを確認すると、理由コードが付与された Reason ヘッダが付与されていることがあります。必ずしも付与されているわけではありませんのでご注意ください。Reason コードが付与される可能性のある SIP メッセージとしては、CANCEL、BYE および SIP レスポンス (18x、4xx、5xx、6xx) があります。切断ガイダンスが流れる場合は 183 Session Progress に、そのガイダンスの内容を示す Reason ヘッダが付与される場合があります。
以下に、IP Phone が存在しない番号にコールして、CUCM が 404 Not Found (理由コード 1) を返信した例を示します。
SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 192.168.1.11:50428;branch=z9hG4bK5e6fb5e5
From: "2000" <sip:2000@192.168.98.130>;tag=c4143c971f24000607f44670-152343a1
To: <sip:2888@192.168.98.130>;tag=2337~66a59a13-d69c-da61-9e0a-ee680a63e08f-24389567
Date: Tue, 01 Dec 2015 06:17:46 GMT
Call-ID: c4143c97-1f240003-1edc3bd2-0cc23264@192.168.1.11
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM10.5
Content-Length: 0
- CDR による理由コードの確認
CUCM で出力される CDR には origCause_value と destCause_value が記録されています。CUCM の発信側で切断された場合には origCause_value に記録され、着信側で切断された場合には destCause_value に記録されます。CDR の内容を確認することによってこれらの値を確認できます。
- TranslatorX による理由コードの確認
TranslatorX のコールリスト機能を使うと、コールの一覧とともに理由コード (Orig Cause、Dest Cause) も表示されます。コールリストは事前に CDR を有効にしている必要がありますのでご注意ください。
TranslatorX で SIP メッセージの Reason ヘッダの理由コードも確認することができます。
- RTMT Session Trace による理由コードの確認
RTMT Session Trace でコールの一覧を表示すると、Termination Cause Code に理由コードが表示されます。
Warning ヘッダによる確認
CUCM は、場合によってはエラーレスポンスに Warning ヘッダを付与して切断理由を返す場合があります。下記は、CUCM が SIP Trunk に登録されていないノードから INVITE を受信した場合に返信するメッセージとなります。
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 192.168.98.238:5060;branch=z9hG4bK17A17
From: <sip:0312345678@192.168.98.238>;tag=6A410D8-B2E
To: <sip:2079@192.168.98.130>;tag=928975043
Date: Tue, 01 Dec 2015 08:23:21 GMT
Call-ID: 1578EB63-C72C11E5-8079B4A9-3325806B@192.168.98.238
CSeq: 101 INVITE
Allow-Events: presence
Warning: 399 cucm105p "Unable to find a device handler for the request received on port 50108 from 192.168.98.238"
Content-Length: 0
(参考) Voice Gateway におけるコールが切断される問題のトラブルシューティング
参 考までに Voice Gateway 側のトラブルシューティング方法についても簡単に紹介します。切断メッセージが CUCM で生成されておらず、Voice Gateway から送信されている場合、そのエラーが Voice Gateway で生成されたものか、PSTN や PBX から送信されたものかをまず確認する必要があります。
例として、SIP-ISDN 接続の場合は、下記のデバッグコマンドでシグナリングメッセージを確認できます。
debug voice ccapi inout
debug ccsip message (SIP シグナリングの確認)
debug isdn q931 (Q931 シグナリングの確認)
詳細なデバッグコマンドについては下記を参照してください。
デバッグを取得する際にはルータの負荷を抑えるために下記を参照してください。
コールが Voice Gateway で切断されている場合には、以下のコマンドを事前に設定することによって、内部エラーコードを SYSLOG で確認することができます。
- 設定
(config)voice iec syslog
- SYSLOG
Jan 1 12:34:56.789: %VOICE_IEC-3-GW: C SCRIPTS: Internal Error (No dialpeer match
内部エラーコードの詳細については下記を参照してください。
また、TranslatorX は、debug ccsip message と debug isdn q931 (SIP のデバッグとの組み合わせが必要) のデバッグ出力にも対応しているため、コールフローや理由コードなども簡単に確認することができます。
サービスリクエストのオープン
環 境や設定を 見直してもコールに失敗する場合は、IP Phone のリセット、CUCM の Cisco CallManager サービスの再起動、CUCM サーバの再起動をご検討ください。それでも改善しない場合は、既に登録されている不具合に該当している可能性もあるため、下記を参照して既存の不具合がな いか確認してみてく ださい。
サービスリクエストをオープンをご検討される場合は、下記の情報をあらかじめ収集することによって問題解決までの期間が短縮されます。
- Step 1 に記載されているトポロジやコールや設定変更に関する情報
- Step 1 ～ 4 までの実施内容とその結果
- CUCM の詳細バージョン (例: 10.5.2.10000-1)
- IP Phone や Voice Gateway などのバージョン
- RTMT より取得した下記のログ
- Cisco CallManager Trace
- Event Viewer Application Logs
- Event Viewer System Logs
参考リンク
- CUCMのトレースログを収集する方法
- TranslatorX によるトレースログのトラブルシューティング
- TranslatorX でコールリストを表示する方法
- TranslatorX で表示されたメッセージをフィルタする方法
- RTMT Session Trace による SIP コールの確認方法
- Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 10.0(1)
- CUCM アプライアンス モデルでのパケット キャプチャ
- Catalyst スイッチド ポート アナライザ（SPAN）の設定例
- ルータ上でパケットキャプチャを取得する方法 (IP Traffic Export)
- Wiresharkによる UC トラブルシューティング （VoIPシグナリングの解析方法）
- 技術参考資料：INSネットサービスのインタフェース
- 理由表示の使用方法及び生成源
- VoIP Cause Codes and Debug Values
- SIP and H.323 Internal Cause Codes
- ボイスゲートウェイで取得すべきデバッグログの一覧
- IOS ルータで適切かつ安全にデバッグ情報を収集する方法
- Cisco VoIP Internal Error Codes (IEC) による切断理由の確認
- Troubleshooting Guide for Cisco Unified Communications Manager, Release 10.0(1)
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
