音声 : ゲートウェイ プロトコル

VoIP コールのトラブルシューティングとデバッグ - 基本

2010 年 7 月 9 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 11 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
ネットワークのコール フロー
ルータのコール フロー
テレフォニー インターフェイス アーキテクチャ
デジタルとアナログのシグナリングの確認(POTS コール レッグ)
      show controllers T1 / E1(デジタル)
      show voice port
      debug vpm(音声処理モジュール)
送受信されたディジットの検証(POTS コール レッグ)
      show dialplan number
      debug vtsp session
エンドツーエンド VoIP シグナリングの確認(VOIP コール レッグ)
      debug voip ccapi inout
VoIP Quality of Service(QoS)の問題の理解
VoIP の原因コードとデバッグ値の詳細
      Q.931 コール接続解除の原因(debug voip ccapi inout の cause_codes)
      コーデック ネゴシエーション値(debug voip ccapi inout から)
      トーン タイプ
      FAX 速度および VAD 機能の値
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

このドキュメントでは、VoIP ネットワークのトラブルシューティングとデバッグに関する基本テクニックとコマンドを紹介します。Cisco ルータの音声コール フローとテレフォニー アーキテクチャの概要を紹介し、その後で、次の VoIP トラブルシューティング方法の手順を説明します。

  1. デジタルとアナログのシグナリングを確認する

  2. アナログとデジタルの音声ポート経由で送受信されるディジットを確認する。

  3. エンドツーエンド VoIP シグナリングを確認する。

  4. VoIP Quality of Service(QoS)の問題を理解する。

  5. VoIP の原因コードとデバッグ値の詳細を理解する。

注:このドキュメントは、Cisco VoIP ゲートウェイとゲートキーパーで使われる Cisco IOS® アーキテクチャのすべての側面を説明しているわけではありません。目的は、どのコマンドが使用できるか、コマンド出力のどのフィールドが最も有益であるかを示すことです。

注意 注意:Cisco IOS のデバッグ作業は、プロセッサに負荷をかける可能性があります。このドキュメントで紹介するデバッグ方法を使用するときには注意が必要です。詳細は、『debug コマンドに関する重要な情報』を参照してください。

デバッグは、ログのタイムスタンプをイネーブルにした状態で実行する必要があります。タイムスタンプをイネーブルにするには、イネーブル モードで、service timestamps debug datetime msecservice timestamps log datetime msec コマンドを追加します。タイムスタンプは、状態変化の時間間隔を調べるのに役立ちます。



前提条件

要件

このドキュメントは、VoIP ネットワークの設計と導入に関係するネットワーク担当者を対象にしています。このドキュメントの読者には、次の項目に関する知識が必要です。

  • VoIP の設定

  • 音声 QoS



使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアに限定されるものではありません。ただし、ここで示す出力は、Cisco IOS® ソフトウェア リリース 12.3(8) に基づくものです。

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



表記法

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



ネットワークのコール フロー

VoIP のトラブルシューティングやデバッグを行う前に考慮しておくべき重要な要素は、VoIP コールが 3 つのコール レッグで構成されているということです。この 3 つのコール レッグとは、送信元 Plain Old Telephone Systems(POTS; 一般電話サービス)、VoIP、宛先 POTS のことです。これを次の図に示します。トラブルシューティングとデバッグでは、最初に各レッグを別個に注目し、その後、VoIP コール全体を注目する必要があります。

call-legs.gif



ルータのコール フロー

call-flow.gif

次の定義では、ルータのコール フロー図に示される主なコンポーネントの機能を説明します。

コール制御 Application Programming Interface(API; アプリケーション プログラミング インターフェイス):3 つのクライアントがコール制御 API を利用しています。その 3 つのクライアントとは、CLI、Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)エージェント、およびセッション アプリケーションです。Calll Control API(CCAPI; コール制御 API)の主な機能は、次のタスクを行うことです。

  • コール レッグを特定する(それがどのダイヤル ピアなのか、どこから来たのかなど)。

  • どのセッション アプリケーションがコールを受け入れるのかを決定する(誰がそれを取り上げるのかなど)。

  • パケット ハンドラを呼び出す。

  • コール レッグをともに協議する。

  • コール統計情報の記録を開始する。

セッション アプリケーションとダイヤル プラン マッパー:セッション アプリケーションは、ダイヤル プラン マッパーを使ってダイヤル ピア(ローカル POTS またはリモート VoIP)に番号をマップします。ダイヤル プラン マッパーは、ダイヤル ピア テーブルを使ってアクティブなダイヤル ピアを検索します。

テレフォニーと VoIP Service Provider Interface(SPI; サービス プロバイダー インターフェイス):テレフォニー SPI は、POTS(アナログ:fxs、fxo、e&m、デジタル:isdn、qsig、e&m など)ダイヤル ピアと通信します。VoIP SPI は、VoIP ピアに対する特定のインターフェイスです。テレフォニー/DSP ドライバはテレフォニー SPI にサービスを配信し、一方で、VoIP SPI はセッション プロトコルに依存します。



テレフォニー インターフェイス アーキテクチャ

この図は、Cisco ルータのテレフォニー基盤のアーキテクチャと、それらが互いにやり取りする方法を示しています。

telephony-int.gif

次のリストは、上の図の主要コンポーネントの機能と定義を示しています。

  • コール制御アプリケーション プログラミング インターフェイス(CCAPI):コール レッグを確立、終了、およびブリッジ処理するソフトウェア エンティティです。

  • Voice Telephony Service Provider(VTSP):コール制御 API からの要求を処理し、Digital Signal Processor(DSP; デジタル シグナル プロセッサ)または VPM への適切な要求を形成する IOS プロセスです。

  • Voice Processor Module(VPM; 音声処理モジュール):VPM は、テレフォニー ポート signaling state machine(SSM)、DSP リソース マネージャ、VTSP 間のシグナリング プロセスをブリッジングして調整することを担当します。

  • DSP Resource Manager(DSPRM; DSP リソース マネージャ):DSPRM は、VTSP が DSP との間でメッセージを送受信するインターフェイスを提供します。

  • パケット ハンドラ:パケット ハンドラは DSP とピア コール レッグとの間でパケットを転送します。

  • コール ピア:コール ピアは相手側のコール レッグです。これは、別のテレフォニー音声接続(POTS)、VoFR、VoATM、または VoIP 接続です。



デジタルとアナログのシグナリングの確認(POTS コール レッグ)

デジタルとアナログのシグナリングを確認する目的は、次のとおりです。

  • 適切なオンフックとオフフックのアナログまたはデジタルのシグナリングが受信されているかどうかを判断すること。

  • 適切な E&M、FXO、および FXS シグナリングがルータとスイッチ(CO または PBX)の両方で設定されているかどうかを判断すること。

  • DSP がディジット収集モードになっていることを確認すること。

これ以降のセクションで概説するコマンドは、シグナリングの確認のために使用できます。



show controllers T1 / E1(デジタル)

show controllers t1 [slot/port]:このコマンドを最初に使用します。このコマンドは、ルータとスイッチ(CO または PBX)の間のデジタル T1 接続がアップまたはダウンしているか、正しく機能しているかを示します。このコマンドの出力は次のようになります。

router# show controllers T1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is Line
Primary.
Data in current interval (6 seconds elapsed):

	0 Line Code Violations, 0 Path Code Violations
	0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 
  0 Degraded Mins
	0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
  0 Unavail Secs

E1 を使用している場合は、show controllers e1 コマンドを使用します。詳細は、次のドキュメントを参照してください。



show voice port

show voice port slot-number/port:このコマンドを使用すると、Cisco voice interface card(VIC; 音声インターフェイス カード)の音声ポートで設定されるポート状態とパラメータが表示されます。すべての IOS コマンドと同様、デフォルトは show running-config では何も表示されませんが、このコマンドでは表示されます。

次に示すのは、E&M 音声ポートのサンプル出力です。

router# show voice port 1/0:1
recEive and transMit Slot is 1, Sub-unit is 0, Port is 1
Type of VoicePort is E&M 
Operation State is DORMANT
Administrative State is UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Music On Hold Threshold is Set to -38 dBm
In Gain is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal (could be trunk or plar)
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Signal Type is wink-start
Operation Type is 2-wire
E&M Type is 1
Dial Type is dtmf
In Seizure is inactive
Out Seizure is inactive
Digit Duration Timing is set to 100 ms

InterDigit Duration Timing is set to 100 ms
Pulse Rate Timing is set to 10 pulses/second
InterDigit Pulse Duration Timing is set to 500 ms
Clear Wait Duration Timing is set to 400 ms
Wink Wait Duration Timing is set to 200 ms
Wink Duration Timing is set to 200 ms
Delay Start Timing is set to 300 ms
Delay Duration Timing is set to 2000 ms
Dial Pulse Min.Delay is set to 140 ms



debug vpm(音声処理モジュール)

次のコマンドは、VPM テレフォニー インターフェイスをデバッグするために使用します。

  • debug vpm signal:このコマンドは、シグナリング イベント用のデバッグ情報を収集するために使用し、PBX へのシグナリングに関する問題を解決する際に役に立つ可能性があります。

  • debug vpm spi:このコマンドは、音声ポート モジュールのサービス プロバイダー インターフェイス(SPI)が、コール制御 API とインターフェイスを取る方法をトレースします。この debug コマンドは、それぞれのネットワーク指定とアプリケーション要求がどのように処理されているかについての情報を表示します。

  • debug vpm dsp:このコマンドは、VPM 上の DSP からルータへのメッセージを表示します。これは、VPM が機能していないと疑われる場合に役に立つコマンドです。これは、VPM がオフフック表示に応答しているかどうかをチェックし、インターフェイスからのシグナリング メッセージのタイミングを評価するための簡単な方法です。

  • debug vpm all:この EXEC コマンドは、すべての debug vpm コマンドである、debug vpm spidebug vpm signal、および debug vpm dsp をイネーブルにします。

  • debug vpm port:このコマンドを使用すると、デバッグの出力を特定のポートに制限できます。たとえば、次の出力は、debug vpm dsp メッセージをポート 1/0/0 だけに表示します。

    debug vpm dsp 
    
    debug vpm port 1/0/0 

    詳細は、『VoIP デバッグ コマンド』を参照してください。

debug vpm signal コマンドのサンプル出力

maui-voip-austin#debug vpm signal


!--- FXS ポート 1/0/0 は「オンフック」状態から「オフフック」状態に 
!--- 変わります。

htsp_process_event: [1/0/0, 1.2 , 36] 
fxsls_onhook_offhook htsp_setup_ind
*Mar 10 16:08:55.958:htsp_process_event: 
[1/0/0, 1.3 , 8] 


!--- 呼び出された側の電話にリング アラートを送信します。

*Mar 10 16:09:02.410: htsp_process_event: 
[1/0/0, 1.3 , 10] htsp_alert_notify
*Mar 10 16:09:03.378: htsp_process_event: 
[1/0/0, 1.3 , 11] 


!--- 通話の終了、ポートは「オンフック」になります。

*Mar 10 16:09:11.966: htsp_process_event: 
[1/0/0, 1.3 , 6] 
*Mar 10 16:09:17.218: htsp_process_event: 
[1/0/0, 1.3 , 28] fxsls_offhook_onhook
*Mar 10 16:09:17.370: htsp_process_event: 
[1/0/0, 1.3 , 41] fxsls_offhook_timer
*Mar 10 16:09:17.382: htsp_process_event: 
[1/0/0, 1.2 , 7] fxsls_onhook_release

オンフックとオフフックが適切にシグナリングしない場合、次の項目を確認します。

  • 配線が正しいことを確認します。

  • ルータとスイッチ(CO または PBX)の両方が適切に接地されていることを確認します。

  • 接続の両端が一致するシグナリング設定になっていることを確認します。一致しない設定は、不完全なシグナリングまたは一方向のシグナリングの原因になる可能性があります。

E&M トラブルシューティングの詳細は、『アナログ E&M インターフェイスのタイプおよび配線の説明とトラブルシューティング』を参照してください。

debug vpm spi コマンドのサンプル出力

maui-voip-austin#debug vpm spi   
Voice Port Module Session debugging is enabled


!--- DSP はディジット収集モードになります。

*Mar 10 16:48:55.710: dsp_digit_collect_on: 
[1/0/0] packet_len=20 channel_id=128
 packet_id=35 min_inter_delay=290 
 max_inter_delay=3200 mim_make_time=18 max_make
 _time=75 min_brake_time=18 max_brake_time=75



送受信されたディジットの検証(POTS コール レッグ)

オンフックとオフフックのシグナリングが確認され、正しく動作しているのであれば、正しいディジットが音声ポート(デジタルまたはアナログ)で送受信されていることを確認します。未完成のまたは不正なディジットが送受信された場合は、ダイヤル ピアが一致しないか、スイッチ(CO または PBX)が正しいステーションを呼び出すことができません。送受信されたディジットの確認に使用できるコマンドには次のものがあります。

  • show dialplan number:このコマンドは、特定の電話番号がダイヤルされたときにどのダイヤル ピアに到達するのかを表示するのに使用されます。

  • debug vtsp session:このコマンドは、各ネットワーク指示とアプリケーション要求が処理される方法、シグナリング指示、DSP 制御メッセージの情報を表示します。

  • debug vtsp dsp:12.3 よりも前の Cisco IOS ソフトウェア リリースでは、このコマンドは、音声ポートが受信したディジットを表示します。ただし、Cisco IOS ソフトウェア リリース 12.3 以降では、debug コマンドの出力にディジットは表示されなくなりました。着信するディジットを確認するには、debug hpi detaildebug hpi notification の組み合わせを使用できます。

  • debug vtsp all:このコマンドによってデバッグ用 voice telephony service provider(VTSP)コマンドである、debug vtsp sessiondebug vtsp errordebug vtsp dsp がイネーブルになります。

詳細は、『VoIP デバッグ コマンド』を参照してください。



show dialplan number

show dialplan number <digit_string>:このコマンドでは、ディジット文字列に一致するダイヤル ピアが表示されます。複数のダイヤル ピアが一致する場合、一致した順序ですべて表示されます。

注:T で終わる宛先パターンで一致させるには、可変長のダイヤル ピアの電話番号の最後に # 記号を使用する必要があります。

このコマンドの出力は次のようになります。

maui-voip-austin#show dialplan number 5000
Dial string terminator: #
Macro Exp.: 5000

VoiceOverIpPeer2
        information type = voice,
       tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation
       state is up,
        incoming called-number = `', 
        connections/maximum = 0/unlimited,
        application associated: 
        type = voip, session-target = 
       `ipv4:192.168.10.2',
        technology prefix: 
        ip precedence = 5, UDP checksum = 
        disabled, session-protocol = cisco, 
        req-qos = best-effort, 
        acc-qos = best-effort, 
        dtmf-relay = cisco-rtp, 
        fax-rate = voice,   
       payload size =  20 bytes
       codec = g729r8,   
       payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,
        signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 25630, Charged Units = 0,
        Successful Calls = 25, Failed Calls = 0,
        Accepted Calls = 25, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call 
        clearing.",
        Last Setup Time = 84427934.
        Matched:5000   Digits: 4
       Target:ipv4:192.168.10.2



debug vtsp session

debug vtsp session コマンドは、シグナリング スタックからのシグナリング指示とアプリケーションからの要求に基づいて、ルータが DSP とやり取りする方法について情報を表示します。この debug コマンドは、それぞれのネットワーク指示とアプリケーション要求が処理される方法、シグナリング指示、および DSP 制御メッセージについての情報を表示します。

maui-voip-austin#debug vtsp session 
Voice telephony call control session debugging is on


!--- 出力を省略。
!--- アクション:発信者が受話器を取りました。 
!--- DSP が割り当てられ、ジッタ バッファ、VAD 
!--- しきい値、信号レベルが設定されます。


*Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)]
packet_len=18 channel_id=1 packet_id=76 mode=1 
initial=60 min=4 max=200 fax_nom=300
*Mar 10 18:14:22.865: dsp_echo_canceller_control: 
[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66
flags=0x0
*Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)] 
packet_len=12 channel_id=1 packet_id=91 
in_gain=0 out_gain=65506
*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)] 
packet_len=10 channel_id=1 packet_id=78 
thresh=-38act_setup_ind_ack 
*Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)] 
packet_len=24 channel_id=1 packet_id=73 coding_type=1
voice_field_size=80 
VAD_flag=0 echo_length=64 comfort_noise=1 
inband_detect=1 digit_relay=2 
AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mod
e()act_setup_ind_ack: passthru_mode = 0, 
no_auto_switchover = 0dsp_dtmf_mode
(VTSP_TONE_DTMF_MODE)


!--- DSP は「音声モード」になり、ダイヤル トーンが 
!--- 生成されます。


*Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)] 
packet_len=30 channel_id=1 packet_id=72 tone_id=4 
n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=
4000 amp_of_second=4000 direction=1 on_time_first=65535 
off_time_first=0 on_time
_second=65535 off_time_second=0

ディジットが正しく送受信されていないと判断した場合、digit-grabber(テスト ツール)または T1 テスターを使用して、ディジットが正しい頻度とタイミング間隔で送信されているかどうかを確認することが必要な可能性があります。スイッチ(CO または PBX)に対してディジットが「不正に」送信されている場合、ルータまたはスイッチ(CO または PBX)上のいくつかの値を一致するように調整して、相互運用ができるようにする必要が出る可能性もあります。調整するのは、通常、digit duration 値または inter-digit duration 値です。ディジットが正しく送信されているかどうかを判断するもう 1 つの項目は、ディジットの追加や削除ができるスイッチ(CO または PBX)内の番号変換テーブルです。



エンドツーエンド VoIP シグナリングの確認(VOIP コール レッグ)

音声ポートのシグナリングが適切に動作しており、正しいディジットが受信されていることを確認した後、VoIP コール制御トラブルシューティングとデバッグに進みます。次のような理由で、コール制御デバッグが複雑な作業になる可能性があります。

  • Cisco VoIP ゲートウェイはコールの完了に H.323 シグナリングを使用しています。H.323 は、コール ネゴシエーションとコール確立の 3 つのレイヤである、H.225、H.245、H.323 から構成されています。これらのプロトコルは、コールのセットアップと確立に TCP と UDP の組み合わせを使用しています。

  • エンドツーエンド VoIP デバッグは、いくつかの IOS state-machine を示します。state-machine に何らかの問題があると、コールが失敗する原因になります。

  • エンドツーエンド VoIP デバッグは、非常に冗長で多量のデバッグ出力を生成する可能性があります。



debug voip ccapi inout

エンドツーエンド VoIP コールをデバッグする主なコマンドは、debug voip ccapi inout です。あるコール デバッグからの出力を次の出力に示します。


!--- アクション:VoIP コールはテレフォニー SPI(POTS レッグ)を経由して、 
!--- 内線番号 5000 宛てに発信されます。 
!--- 出力を一部省略。


maui-voip-austin#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on


!--- コール レッグ識別、送信元ピア: 
!--- ダイヤル ピア 1 POTS から発信されたコール 
!--- (内線番号 4000)。


*Mar 15 22:07:11.959: cc_api_call_setup_ind 
(vdbPtr=0x81B09EFC, callInfo={called=, 
calling=4000, fdest=0 peer_tag=1}, callID=0x81B628F0)

!--- CCAPI は、セッション アプリケーションを起動します。


*Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"
*Mar 15 22:07:11.963: sess_appl: 
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)


!--- コール レッグ識別子「callid = 0x59」を割り当てます。


*Mar 15 22:07:11.963: ccCallSetContext 
(callID=0x58, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck 
(callID=0x58)


!--- VTSP に対してダイヤルトーンを生成するように指示します。
. 

*Mar 15 22:07:11.963: ccGenerateTone 
(callID=0x58 tone=8)


!--- VTSP はディジットを CCAPI に渡します。


*Mar 15 22:07:20.275:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:20.279: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:20.279: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:20.279: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:20.327: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=5
, duration=100)
*Mar 15 22:07:20.327: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:20.327: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.975:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:21.979: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:21.979: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.979: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:22.075: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:22.079: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:22.079: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.235: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, dgit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:23.239: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:23.239: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.239: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:23.335: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:23.339: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:23.339: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:25.147: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, d
igit=0, flags=0x1, timestamp=0xC2E63BB7, 
expiration=0x0)
*Mar 15 22:07:25.147: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:25.147: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:25.147: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:25.255: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=160)
*Mar 15 22:07:25.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:25.259: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)


!--- ダイヤル ピア 2 voip と一致しました。宛先番号 
!--- 5000


*Mar 15 22:07:25.259: ssaSetupPeer cid(88) 
peer list:tag(2) called number(5000) 
*Mar 15 22:07:25.259: ssaSetupPeer cid(88), 
destPat(5000), matched(4), prefix(),
peer(81C04A10)


!--- インターフェイスの呼び出しを継続して、次の 
!--- コール レッグを開始します。


*Mar 15 22:07:25.259: ccCallProceeding 
(callID=0x58, prog_ind=0x0)
*Mar 15 22:07:25.259: ccCallSetupRequest 
(Inbound call = 0x58, outbound peer =2,
dest=, params=0x81BAF168 mode=0, 
*callID=0x81B6DE58)
*Mar 15 22:07:25.259: callingNumber=4000, 
calledNumber=5000, redirectNumber=


!--- VoIP コール セットアップ。


*Mar 15 22:07:25.263: ccIFCallSetupRequest:
(vdbPtr=0x81A75558, dest=, 
callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}, mode=0x0)
*Mar 15 22:07:25.263: ccCallSetContext 
(callID=0x59, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert 
(callID=0x58, prog_ind=0x8, sig_ind=0x1)


!--- POTS と VoIP のコール レッグが結び付けられます。


*Mar 15 22:07:25.375: ccConferenceCreate 
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)
*Mar 15 22:07:25.375: cc_api_bridge_done 
(confID=0x1E, srcIF=0x81B09EFC, srcCall
ID=0x58, dstCallID=0x59, disposition=0, 
tag=0x0)


!--- 機能ビットマスクをリモート 
!--- VoIP ゲートウェイ
!--- (コーデック、VAD、VoIP または FAX、FAX 速度など)と交換します。


*Mar 15 22:07:26.127: cc_api_caps_ind 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59,caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20, 
signal_type=0})


!--- 両方のゲートウェイが機能について合意します。

*Mar 15 22:07:26.127: cc_api_caps_ack 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59, caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:26.139: cc_api_caps_ack 
(dstVdbPtr=0x81A75558, dstCallId=0x59, src
CallId=0x58, caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:35.259: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=T
, duration=0)
*Mar 15 22:07:35.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:35.259: ssaTraceSct: 
cid(88)st(4)oldst(3)cfid(30)csize(0)in(1)
fDest(0)-cid2(89)st2(4)oldst2(1)
*Mar 15 22:07:35.399: cc_api_call_connected
(vdbPtr=0x81A75558, callID=0x59)
*Mar 15 22:07:35.399: sess_appl: 
ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0)
*Mar 15 22:07:35.399: ssaTraceSct: 
cid(89)st(4)oldst(1)cfid(30)csize(0)in(0)
fDest(0)-cid2(88)st2(4)oldst2(4)


!--- VoIP コールは接続されます。


*Mar 15 22:07:35.399: ccCallConnect 
(callID=0x58)


!--- VoIP コールは接続を解除されます。原因 = 0x10
 

*Mar 15 23:29:39.530: ccCallDisconnect 
(callID=0x5B, cause=0x10 tag=0x0)

コールが失敗し、その原因がコール セットアップの VoIP 部分にあるように思われる場合、H.323 セットアップの UDP 部分だけではなく、コール セットアップの H.225 または H.245 TCP 部分を確認する必要がある可能性があります。H.225 または H.245 コール セットアップをデバッグするために使用できるコマンドは次のとおりです。

  • debug ip tcp transactionsdebug ip tcp packet:これらのコマンドは、H.225 と H.245 のネゴシエーションの TCP 部分を検査します。IP アドレス、TCP ポート、TCP 接続の状態が返されます。

  • debug cch323 h225:このコマンドは、コール ネゴシエーションの H.225 部分を検査して、処理されたイベントに基づいて H.225 state machine の状態遷移をトレースします。これを H.323 コール セットアップの 3 つの部分のレイヤ 1 部分と見なします。

  • debug cch323 h245:このコマンドは、コール ネゴシエーションの H.245 部分を検査して、処理されたイベントに基づいて H.245 state machine の状態遷移をトレースします。これを H.323 コール セットアップの 3 つの部分のレイヤ 2 部分と見なします。



VoIP Quality of Service(QoS)の問題の理解

VoIP コールが適切に確立されたら、次の手順は音声品質が良好であるかどうかを確認することです。QoS のトラブルシューティングはこのドキュメントの対象外ですが、次のガイドラインは、良好な音声品質を実現するために考慮する必要があります。

  • VoIP コールが各コーデックでどの程度帯域幅を消費するのかを理解します。これには、レイヤ 2 と IP/UDP/RTP ヘッダーが含まれています。詳細は、『VoIP - コール単位の帯域幅の使用量』を参照してください。

  • コールが通過する IP ネットワークの特性を理解します。たとえば、CIR のフレーム リレー ネットワークの帯域幅は、CIR を超過しているもの(またはバースト)の帯域幅とはかなり異なっています。超過する場合は、パケットがフレーム リレー クラウド内で廃棄またはキューイングされる可能性があります。可能な限り、遅延とジッタを制御し、排除するようにします。一方向の転送遅延は、150 ミリ秒以内にします(G.114 勧告による)。

  • VoIP トラフィックが特定され、優先順位付けされることを許可するキューイング テクニックを使用します。

  • 低速リンク経由で VoIP を転送するときには、ポイントツーポイント リンクでの Link Fragmentation and Interleaving(LFI)を備えた MLPPP、フレーム リレー リンクでの FRF.12 など、レイヤ 2 パケット フラグメンテーション テクニックの使用を検討してください。より大きなデータ パケットのフラグメンテーションによって、VoIP トラフィックの転送におけるジッタと遅延が比較的少なくなります。その理由は、VoIP パケットがリンク上でインターリーブできるためです。

  • 別のコーデックを使用したり、VAD をイネーブルおよびディセーブルにしてコールを行ったりすると、問題を IP ネットワークに対するのではなく、DSP に絞り込める可能性があります。

VoIP における QoS 問題のトラブルシューティングでは、廃棄されたパケットと、遅延およびジッタの原因となるネットワーク ボトルネックについて主に調査します。

次を調査します。

  • インターフェイス廃棄

  • バッファ廃棄

  • インターフェイス輻輳

  • リンク輻輳

VoIP コールのパスにあるそれぞれのインターフェイスは、検査する必要があります。また、廃棄と輻輳を排除します。また、ラウンドトリップ遅延はできるだけ短縮する必要があります。VoIP エンド ポイント間で ping を実行すると、リンクのラウンドトリップ遅延がわかります。ラウンドトリップ遅延は、できるだけ 300 ミリ秒以内にする必要があります。遅延がやむを得ずこの値を上回る場合は、この遅延を必ず一定にして、ジッタや可変遅延を招かないようにする必要があります。

また、IOS キューイング メカニズムが VoIP パケットを適切なキューの中に配置することを確認する必要もあります。キューイングの確認には、show queue interfaceshow priority などの IOS コマンドが役に立ちます。



VoIP の原因コードとデバッグ値の詳細

デバッグと、デバッグ内の関連する値を読み取るときには、次の表を使用します。



Q.931 コール接続解除の原因(debug voip ccapi inout の cause_codes)

Q.931 原因コードと値の詳細は、『ISDN スイッチ タイプ、コード、および値』を参照してください。

コール接続解除原因の値(16 進数)

意味と番号(10 進数)

CC_CAUSE_UANUM = 0x1

未割り当て番号 (1)

CC_CAUSE_NO_ROUTE = 0x3

宛先へのルートがない (3)

CC_CAUSE_NORM = 0x10

正常なコール クリア (16)

CC_CAUSE_BUSY = 0x11

ユーザがビジー (17)

CC_CAUSE_NORS = 0x12

ユーザからの応答がない (18)

CC_CAUSE_NOAN = 0x13

ユーザからの返答がない (19)

CC_CAUSE_REJECT = 0x15

コールが拒否された (21)

CC_CAUSE_INVALID_NUMBER = 0x1C

無効な番号 (28)

CC_CAUSE_UNSP = 0x1F

正常、指定されていない (31)

CC_CAUSE_NO_CIRCUIT = 0x22

回線がない (34)

CC_CAUSE_NO_REQ_CIRCUIT = 0x2C

要求された回線がない (44)

CC_CAUSE_NO_RESOURCE = 0x2F

リソースがない (47) 1

CC_CAUSE_NOSV = 0x3F

サービスまたはオプションが利用可能ではないか、指定されていない (63)

1 この問題は、H323 セットアップ内のコーデック不一致のために発生する可能性があるので、トラブルシューティングの最初の手順は、VoIP ダイヤル ピアをハードコードして、正しいコーデックを使用することです。



コーデック ネゴシエーション値(debug voip ccapi inout から)

コーデックの詳細は、『コーデックについて:複雑度、ハードウェア サポート、MOS、およびネゴシエーション』を参照してください。

ネゴシエーション値

意味

codec=0x00000001

G711 ULAW 64K PCM

codec=0x00000002

G711 ALAW 64K PCM

codec=0x00000004

G729

codec=0x00000004

G729IETF

codec=0x00000008

G729a

codec=0x00000010

G726r16

codec=0x00000020

G726r24

codec=0x00000040

G726r32

codec=0x00000080

G728

codec=0x00000100

G723r63

codec=0x00000200

G723r53

codec=0x00000400

GSMFR

codec=0x00000800

G729b

codec=0x00001000

G729ab

codec=0x00002000

G723ar63

codec=0x00004000

G723ar53

codec=0x00008000

CLEAR_CHANNEL




トーン タイプ

トーン タイプ

意味

CC_TONE_RINGBACK 0x1

呼び出しトーン

CC_TONE_FAX 0x2

FAX トーン

CC_TONE_BUSY 0x4

ビジー トーン

CC_TONE_DIALTONE 0x8

ダイヤル トーン

CC_TONE_OOS 0x10

アウト オブ サービス トーン

CC_TONE_ADDR_ACK 0x20

アドレス確認応答トーン

CC_TONE_DISCONNECT 0x40

接続解除トーン

CC_TONE_OFF_HOOK_NOTICE 0x80

電話がオフフックのままだったことを示すトーン

CC_TONE_OFF_HOOK_ALERT 0x100

CC_TONE_OFF_HOOK_NOTICE のさらに緊急なバージョン

CC_TONE_CUSTOM 0x200

カスタム トーン - カスタム トーンを指定するときに使用される

CC_TONE_NULL 0x0

ヌル トーン




FAX 速度および VAD 機能の値

意味

CC_CAP_FAX_NONE 0x1

FAX がディセーブルであるか、利用可能ではない

CC_CAP_FAX_VOICE 0x2

音声コール

CC_CAP_FAX_144 0x4

14,400 ボー

CC_CAP_FAX_96 0x8

9,600 ボー

CC_CAP_FAX_72 0x10

7,200 ボー

CC_CAP_FAX_48 0x20

4,800 ボー

CC_CAP_FAX_24 0x40

2,400 ボー

CC_CAP_VAD_OFF 0x1

VAD がディセーブルである

CC_CAP_VAD_ON 0x2

VAD がイネーブルである





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

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


関連情報




Document ID: 14081