アカウントをお持ちの場合

  •   パーソナライズされたコンテンツ
  •   製品とサポート

アカウントをお持ちでない場合

アカウントを作成

MGCP のハングしたコールでの PGW 2200 ソフトスイッチのエラー解決

ダウンロード オプション

  • PDF     (290.6 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (81.6 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (94.0 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2006 年 2 月 2 日
Document ID:50501
翻訳について

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

Document ID: 50501

Updated: 2006 年 2 月 02 日

概要

このドキュメントでは、Call Control Cisco PGW 2200 Softswitch ソリューションのゲートウェイでハングしたコールに関連する項目を、トラブルシューティングに役立つシナリオと組み合わせて説明します。 現在、Cisco IOS® ゲートウェイには Service Processing Elements（SPE）（『Understanding NextPort SPE Versions』で説明）を Digital Service 0（DS0）およびメディア ゲートウェイ コントロール プロトコル（MGCP）接続に関連付ける機能はありません。 Cisco IOS デバッグがない場合、MGCP ベースのコール タイプに対して Cisco IOS コマンド show tdm mapping を使用してデジタル シグナル プロセッサ（DSP）に DS0 をマッピングすることは不可能です。 Cisco バグ ID CSCdz47711 （登録ユーザのみ）は AS5350、AS5400 および AS5850 Cisco IOSゲートウェイのためのこの状況を解決するために導入されます。

前提条件

要件

このドキュメントの読者は次のトピックについて理解している必要があります。

使用するコンポーネント

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

  • Cisco PGW 2200 ソフトウェア リリース 9.3(2) および 9.4(1)

  • Cisco IOSゲートウェイ リリース 12.3 および 12.3T

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

表記法

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

MGCP によってハングさせる Call エラーを解決して下さい

ハングさせた MGCP コール シナリオを経験する場合、デバッグの使用は役立ちません。 また、ライブ システムのために、DS0 および MGCP 接続に同期ペイロード エンベロープ（SPE）を関連させることも困難です。 アクティブ コールのための DS0 および DSP を関連させたいと思う場合この資料は説明を提供したものです。

PGW 2200 で、始める前に、MgcpBehavior 設定（使用 マン-マシン言語[MML]）その値が Cisco IOSゲートウェイのための等号 2 あることを確認して下さい。 詳細については資料 XECfgParm.dat ファイル パラメータを参照して下さい。

PGW 2200 バージョン 9.1(5):

  • 501 エラーコードを受取り次第 MgcpBehavior 等号 1 （基づかなかった on Cisco IOS software ではない Cisco 音声インターワーキング サービス モジュール[VISM]および Cisco MGX）のようなゲートウェイが、状態に、PGW 2200 それ以上の使用を防ぐために回線を設定 します。 詳細については資料コンポーネントおよび Properties を参照して下さい。

  • それ以上の使用を防ぐために MgcpBehavior が状態に、501 エラーコードを受取り次第、2 つに（Cisco IOSゲートウェイ） PGW 2200 設定 すれば 回線を匹敵すれば。 最初の Create Connection （CRCX）に応じての 502 エラーコードを受取り次第、PGW 2200 は別の MGCP CRCX メッセージに先行している MGCP Delete Connection （DLCX）メッセージを送信 します。 もう 502 エラーコードが Cisco IOSゲートウェイによって戻る場合、コールはリリースされます。 想定は回線が再度使用可能であることです。 詳細については資料コンポーネントおよび Properties を参照して下さい。

PGW 2200 バージョン 9.2(2) および それ 以降:

  • MgcpBehavior が匹敵すれば 1 つは（VISM および MGX のために）、501 エラーコードを受取り次第状態に、PGW 2200 それ以上の使用を防ぐために回線を設定 します。

  • それ以上の使用を防ぐために MgcpBehavior が状態に、501 エラーコードを受取り次第、2 つに（Cisco IOSゲートウェイ） PGW 2200 設定 すれば 回線を匹敵すれば。 502 エラーコードを受取り次第（最初の MGCP CRCX メッセージのために）、PGW 2200 は別の MGCP CRCX メッセージに先行している MGCP DLCX メッセージを送信 します。 PGW 2200 がもう 502 エラーコードを受け取る場合、コールはリリースされます。 回線は状態にそれ以上の使用を防ぐために設定 されます。 同時に、回線はバックグラウンド（小型）監査が実行された回線のリストに含まれています。 この監査は PGW 2200 との同期の回線状態を連れて来ることを試みるように小型監査表のすべての回線のための強制 MGCP DLCX メッセージを送信 します。

MGCP 応答タイムアウトは一時失敗 GW_HELD 状態のように扱われ、MGCP DLCX メッセージは毎分再試行します。 MgcpBehavior 特性が正しく設定される場合エラーコード特別な 501/502 のの Restart In Progress （RSIP） （/強制しました段階的）メッセージ、MGCP エラー コード 500、または 1 の受け取りにより常置障害を引き起こします。 「エンドポイント未知数に」。一致するのでエラーコード 500 が MgcpBehavior に関係なく失敗を、常に引き起こすことに注意して下さい、

注: PGW 2200 によって 9.5(2) およびそれ以降を、PGW 2200 設定しました MGCP 1.0 をリリースして下さい。 これはより多くのロバストネスおよびよりよいエラー処理手順を提供します。

メッセージ Cisco IOSソフトウェア（5xxx）
CRCX 502
Modify Connection （MDCX） 515
DLCX 250
通知要求（RQNT） 400
Audit Endpoint （AUEP） 500

この理由は PGW 2200 にネットワーク要素とチャンネルステートを、通信する Cisco IOSゲートウェイのような同期する監査 メカニズムがあるということであるといえます。 PGW 2200 の監査 プログラムは 4:00 AM で動作します（0400）毎朝異なるシナリオに従ってこれらの操作をし、:

  • シナリオ 1： チャンネルステートが PGW 2200、また Cisco IOSゲートウェイで忙しいとき、操作がありません。

  • シナリオ 2： チャンネルステートが PGW 2200、また Cisco IOSゲートウェイの IDLE のとき、MGCP DLCX はそのエンドポイントのための Cisco IOSゲートウェイに送信 されます。 これはハングさせた接続を、存在 するそれクリアします。

  • シナリオ 3： チャンネルステートが Cisco IOSゲートウェイの PGW 2200 および IDLE で忙しいとき、PGW 2200 はコールをリリースし、対応した エンドポイントのための Cisco IOSゲートウェイに Cisco IOSゲートウェイを同期するために DLCX を送信 します。

  • シナリオ 4： チャネルが PGW 2200 の IDLE および Cisco IOSゲートウェイの使用中のとき、PGW 2200 は対応した エンドポイントのための Cisco IOSゲートウェイに Cisco IOSゲートウェイを同期するために MGCP DLCX を送信 します。 PGW 2200 および Cisco IOSゲートウェイはプロシージャをクリアします Cisco IOSゲートウェイのチャネルを監査します。

    Message Definition Language （MDL）が呼び出す初期処理手順がアイドル状態に回線を持って来ません場合エンドポイントを無効としてマークし、エンジンの特別ハングさせた/残されたエンドポイント 監査 メカニズムのためのエントリを作成するためにエンジン インターフェイスを呼び出します。

    Cisco IOSゲートウェイの MgcpBehavior 値を変更するために、2.に MGCPPATHs の MgcpBehavior プロパティを変更して下さい。 

    mml> prov-sta::srcver="active",dstver="cisco1" 
mml> prov-ed:sigsvcprop:name="sigmgcpto5xxx",MgcpBehavior="2" 
mml> prov-cpy

    注: 場合によっては、Cisco IOSゲートウェイのリロードはきれいな状況から再度開始するように要求されます。 これをする前に、一部は Cisco IOSゲートウェイのロギングを問題の解決を助けることができます詳述します。

show コマンド

ここに説明されている show コマンドはハングさせたコールの検証 および トラブルシューティングと助けることができます。

特定の show コマンドは、Output Interpreter Tool（登録ユーザ専用）によってサポートされています。このツールを使用すると、show コマンド出力の分析を表示できます。

もっと show call active voice コンパクト期間か。 コマンドは Cisco IOSゲートウェイのずっと期間呼び出しを見つけるのを助けることができます:

V5xxx-3# show call active voice compact duration more ? 
  <1-2147483647>  time in seconds 
V5xxx-3#

show call active voice brief | 期間 4d コマンドをまたガイドラインを提供できます含んで下さい: 

V5xxx-3# show call active voice brief | include duration 4d 
V5xxx-3# show call active voice brief | include duration ? 
LINE    <cr> 

V5xxx-3#

これらの show コマンドはハングさせたコールの判別を助けることができます:

  • show mgcp statistics —受け取られ、送信されたネットワークメッセージについての MGCP 統計情報を表示する。

  • show mgcp connection — MGCP によって制御されるアクティブな接続のための情報を表示する。

  • rtpspi 統計情報ディスプレイにリアルタイムトランスポートプロトコル （RTP） サービスプロバイダーインターフェイス（SPI）統計情報を表示して下さい。

  • 示して下さい IP ソケット— IP ソケット 情報を表示する。

  • show voice call summary —すべての音声ポートの要約を表示する。

  • show voice port summary —特定の音声ポートについてのサマリ構成情報を表示する。

  • 示して下さい vtsp コール fsm —すべての音声テレフォニーサービスプロバイダー（VTSP）有限状態マシン （FSM）遷移の完全な履歴を表示する。

  • show csm 音声—コールスイッチングモジュール（CSM）に関連情報を表示する。 情報はマシンがコールのその DSP チャネル、開始時刻、コールの終了時刻、およびコールによって使用されるコントローラのチャネルに関連付けられるコールのためにあること CSM 状態です。

    注: それが MGCP Signaling System 7(SS7) である場合、このコマンドは多くの使用ではないです。

  • show spe — SPE ステータスを表示する。

  • spe が音声 summary — SPE 音声ステータスを表示することを示して下さい。

  • show port operational-status スロット/ポート（疑われた DSP のために） —規定 された スロットおよび SPE のすべてのポートのための情報を表示する。

  • show port voice ログ 反転 スロット/ポート（疑われた DSP のために） —規定 された スロットおよび SPE のすべてのポートのための情報を表示する。

一連の show コマンドの情報はこのコールのための Call_ID©）情報を（太字で強調表示される）含む AS5xxx ゲートウェイを通って参照 MGCP に続く呼出します。 これは解決したいと思うときまた重要のためにです。 MGCP エンドポイントは Cisco IOSソフトウェア debug mgcp packet コマンドまたは Cisco スヌーパ アプリケーションと見つけることができます。 

V5xxx-3# show mgcp connection 
Endpoint  Call_ID©) Conn_ID(I) (P)ort (M)ode (S)tate (CO)dec (E)vent[SIFL] 
(R)esult[EA] 
1. S3/DS1-0/1   C=2F,1,2     I=0x2  P=16628,17204  M=3  S=4,4  
CO=2  E=0,0,0,0  R=0,0

注: Cisco PGW 2200 の Troubleshoot 消音呼び出しの MGCP モードにリンクされる M ステータスをチェックして下さい。

show call active voice brief コマンドは transmit （tx） /receive （Rx）パケット情報で情報を提供します。 

V5xxx-3# show call active voice brief 

Telephony call-legs: 1 
SIP call-legs: 0 
H323 call-legs: 0 
MGCP call-legs: 1 
Multicast call-legs: 0 
Total call-legs: 2 
11DA : 37079hs.1 +-1 pid:0 Originate  connecting 
 dur 00:00:00 tx:1198/189454 rx:113437/18149920 
 IP 10.48.84.217:17204 rtt:0ms pl:16000/1290ms lost:29/34/29 delay:30/25/110ms 
 g711alaw 
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a 
11DA : 37079hs.2 +0 pid:52 Originate  active 
 dur 00:37:50 tx:113437/18149920 rx:1198/189454 
 Tele 3/0:0 (1) [3/0.1] tx:2270655/3000/0ms g711alaw noise:-65 
 acom:90  I/0:-51/-45 dBm 

Telephony call-legs: 1 
SIP call-legs: 0 
H323 call-legs: 0 
MGCP call-legs: 1 
Multicast call-legs: 0 
Total call-legs: 2 

v5xxx-3#

リモートゲートウェイ 詳細を調べるために提示 voip rtp 接続コマンドを発行して下さい。 これらはそのコールのための CallId 情報が含まれています。 （この場合、CallId は 1.）あります 

v5xxx-3# show voip rtp connections 
VoIP RTP active connections : 
No. CallId  dstCallId  LocalRTP RmtRTP LocalIP    RemoteIP 
1         2     1          16628     17204    10.48.84.26  10.48.84.217 
Found 1 active RTP connections 

v5xxx-3#

提示 vtsp コール fsm コマンドは非表示 Cisco IOSソフトウェアコマンドで、Cisco テクニカル サポートおよび Cisco 開発チームのためにだけ使用されます。 このコマンドで、句「無効 FSM」を使うとエンクロージャを探すことができます。 提示 vtsp コール fsm コマンドはすべての VTSP FSM 遷移の完全な履歴を表示するものです。 それは debug vtsp error Command Line Interface （CLI）がつく間、どの DSP 問題でも発生する時はいつでも自動的に引き起こされます。

注: また ID = 0x1 与える hex に CallId を = 1 変換できます。 

V5xxx-3# show vtsp call fsm 

0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
id=0x1 state=S_CONNECT chan_id=3/0:0 (1) DSM state=S_DSM_BRIDGED 
Stack 0: 
State Transitions: timestamp (state, event) -> (state, event) ... 
370.796 (S_SETUP_REQUEST, E_TSP_PROCEEDING) -> 
370.796 (S_SETUP_REQ_PROC, E_TSP_CONNECT) -> 
Event Counts (zeros not shown): (event, count) 
(E_TSP_PROCEEDING, 2) :(E_TSP_CONNECT, 2) : 
State Counts (zeros not shown): (state, count) 
(S_SETUP_REQ_PROC, 2) :(S_SETUP_REQUEST, 2) : 
  

--------------------- DSM basic call state information --------------------- 
id=0x1 state=S_DSM_BRIDGED chan_id=0 
Stack 0: 
State Transitions: timestamp (state, event) -> (state, event) ... 
370.796 (S_DSM_INIT, E_DSM_CC_GEN_TONE) -> 
370.796 (S_DSM_INIT, E_DSM_CC_CALL_MODIFY) -> 
370.796 (S_DSM_INIT, E_DSM_CC_BRIDGE) -> 
370.800 (S_DSM_BRIDGING, E_DSM_CC_CAPS_IND) -> 
370.800 (S_DSM_BRIDGING, E_DSM_CC_CAPS_ACK) -> 
475.764 (S_DSM_BRIDGED, E_DSM_CC_GET_LEVELS) -> 
2641.564 (S_DSM_BRIDGED, E_DSM_CC_GET_LEVELS) -> 
Event Counts (zeros not shown): (event, count) 
(E_DSM_DSP_GET_VP_DELAY, 496) :(E_DSM_DSP_GET_VP_ERROR, 496) :(E_DSM_DSP_GET_TX, 
 496) :(E_DSM_DSP_GET_RX, 496) 
(E_DSM_DSP_GET_LEVELS, 2) :(E_DSM_CC_BRIDGE, 1) :(E_DSM_CC_GEN_TONE, 1) :
 (E_DSM_CC_REQ_PACK_STAT, 496) 
(E_DSM_CC_CAPS_IND, 1) :(E_DSM_CC_CAPS_ACK, 1) :(E_DSM_CC_CALL_MODIFY, 1) :
 (E_DSM_CC_GET_LEVELS, 2) 

State Counts (zeros not shown): (state, count) 
(S_DSM_INIT, 3) :(S_DSM_BRIDGING, 2) :(S_DSM_BRIDGED, 2484) : 

v5xxx-3#

どので DSP をコールが接続されているか調べるために、コマンドを示し、TDM マッピングをトレースしているエンドポイントにリンクします詳細を発行して下さい。 この場合、それは S3/DS1-0/1 です: 

v5xxx-3# show tdm mapping 

E1 3/0 is up: 
Loopback: NONE 
DS0      Resource    Call Type 
----------------------------------- 

1          1/0         VOICE 

E1 3/1 is up: 
Loopback: NONE 
DS0      Resource    Call Type 
----------------------------------- 

v5xxx-3#

これは SPE 1 に接続されます、ポート 1.はポートおよび呼び出し状態を調べる show spe コマンドを発行します。 

v5xxx-3# show spe 
Settings  : 
========== 
Country code config : default T1 (u Law) 
Country code setting: e1-default 
History log events  : 50(per port) 
Legend    : 
========== 
Port state: (s)shutdown   (r)recovery  (t)test  (a)active call 
            (b)busiedout  (d)download  (B)bad   (p)busyout pending 
Call type : (m)modem      (d)digital   (v)voice (f)fax-relay       (_)not in use 

Summary   : 
========== 
Ports     : Total   60  In-use     1  Free    59  Disabled     0 
Calls     : Modem    0  Digital    0  Voice    1  Fax-relay    0 

                     SPE          SPE     SPE  SPE   Port         Call 
SPE#    Port #       State        Busyout Shut Crash State        Type 
1/00    0000-0005    ACTIVE             0    0     0 a_____       v_____ 
1/01    0006-0011    ACTIVE             0    0     0 ______       ______ 
1/02    0012-0017    ACTIVE             0    0     0 ______       ______ 
1/03    0018-0023    ACTIVE             0    0     0 ______       ______ 
1/04    0024-0029    ACTIVE             0    0     0 ______       ______ 
1/05    0030-0035    ACTIVE             0    0     0 ______       ______ 
1/06    0036-0041    ACTIVE             0    0     0 ______       ______ 
1/07    0042-0047    ACTIVE             0    0     0 ______       ______ 
1/08    0048-0053    ACTIVE             0    0     0 ______       ______ 
1/09    0054-0059    ACTIVE             0    0     0 ______       ______ 

v5xxx-3#

この場合、show port operational-status 1/0 コマンドを発行する場合パケットがまだその SPE ポートで送信されるかどうか調べることができ、（疑われた DSP のために）: 

v5xxx-3# show port operational-status 1/0   
Slot/SPE/Port -- 1/0/0 
Service Type                            : Voice service 
Voice Codec                             : G.711 a-law 
Echo Canceler Length                    : 8 ms 
Echo Cancellation Control               : Echo cancellation       - disabled 
                                          Echo update             - enabled 
                                          Non-linear processor    - enabled 
                                          Echo reset coefficients - disabled 
                                          High pass filter enable - disabled 
Digit detection enable                  : DTMF signaling          - enabled 
Voice activity detection                : Enabled 
Comfort noise generation                : Generate comfort noise 
Digit relay enable                      : OOB Digit relay         - enabled 
                                          IB Digit relay          - enabled 
Information field size                  : 20 ms 
Playout de-jitter mode                  : adaptive 
Encapsulation protocol                  : RTP 
Input Gain                              : 0.0 dB 
Output Gain                             : 0.0 dB 
Tx/Rx SSRC                              : 24/0 
Current playout delay                   : 30 ms 
Min/Max playout delay                   : 25/110 ms 
Clock offset                            : 180505398 ms 
Predictive concealment                  : 0 ms 
Interpolative concealment               : 1105 ms 
Silence concealment                     : 0 ms 
Buffer overflow discards                : 19 
End-point detection errors              : 23 
Tx/Rx Voice packets                     : 944/88273 
Tx/Rx signaling packets                 : 0/0 
Tx/Rx comfort noise packets             : 11/0 
Tx/Rx duration                          : 1767250/1767250 ms 
Tx/Rx voice duration                    : 3000/16000 ms 
Out of sequence packets                 : 0 
Bad protocol headers                    : 0 
Num. of late packets                    : 23 
Num. of early packets                   : 28 
Tx/Rx Power                             : -45.2/-51.2 dBm 
Tx/Rx Mean                              : -44.3/-51.0 dBm 
VAD Background noise level              : -65.8 dBm 
ERL level                               : 27.7 dB 
ACOM level                              : 90.1 dB 
Tx/Rx current activity                  : silence/silence 
Tx/Rx byte count                        : 151051/14123360 
ECAN Background noise level             : 0.0 dBm 
Latest SSRC value                       : 4144068239 
Number of SSRC changes                  : 1 
Number of payload violations            : 0 

v5350-3#

このコマンドをリモートゲートウェイと組み合わせてある接続の種類で詳細を提供する数回発行して下さい。 ステータスを調べるためにローカル/リモートゲートウェイのこのコマンドを発行して下さい。

ハングさせたコールがある場合、debug vtsp error および debug mgcp packet エンドポイント S3/DS1-0/1 コマンドを発行できます。 MGCP エンドポイントをダウンさせるとき、結果はこのデバッグ メッセージです: 

Apr  9 12:30:18.602: MGCP Packet received from 10.48.84.25:2427- 
DLCX 617 S3/DS1-0/1@v5300-3.cisco.com MGCP 0.1 
C: 1C 
I: 4D 
R: 
S: 
X: 268 
Apr  9 12:30:18.626: 250 617 OK 
P: PS=128, OS=20241, PR=16615, OR=2658400, PL=4, JI=24, LA=0

これらのコマンドはまた役立ちます:

v5xxx-3# show voice call summary 
PORT           CODEC    VAD VTSP STATE       VPM STATE 
============== ======== === ==================== 
3/0:0.1            g711alaw  y     S_CONNECT 

v5xxx-3# show voice port summary 
                                     IN       OUT 
PORT      CH   SIG-TYPE   ADMIN OPER STATUS   STATUS   EC 
========= == ============ ===== ==== ======== ======== == 
3/0:0     01    xcc-voice   up   none  none   none     y 

v5xxx-3#

show mgcp statistics コマンドはまた接続の失敗で詳細を提供します。 壊れるフィールド 情報を理解することを試みて下さい。 壊れる MGCP 接続の原因の 1 つは PGW 2200 が CRCX を送信 するときエンドポイント レポートが一時モードに、一時的に利用できなくというファクトです。 PGW 2200 は原因および試みとして一時的 な 障害とそれから一時モードにだけあったのでそのエンドポイント後で再度リリースします。 これらの SS7 回路 識別識別コード（CIC）に MGCP 接続がありません。 この状況の理由はゲートウェイの MGCP が 400 の MGCP エラー コード（Cisco IOSゲートウェイによって送信 される新しい CRCX メッセージのための一時的 な 障害）を戻すことです。 

v5xxx-3# show mgcp statistics 
 UDP pkts rx 306, tx 330 
 Unrecognized rx pkts 0, MGCP message parsing errors 0 
 Duplicate MGCP ack tx 0, Invalid versions count 0 
 CreateConn rx 0, successful 0, failed 0 
 DeleteConn rx 0, successful 0, failed 0 
 ModifyConn rx 0, successful 0, failed 0 
 DeleteConn tx 0, successful 0, failed 0 
 NotifyRequest rx 0, successful 0, failed 0 
 AuditConnection rx 0, successful 0, failed 0 
 AuditEndpoint rx 306, successful 305, failed 1 
 RestartInProgress tx 1, successful 1, failed 0 
 Notify tx 0, successful 0, failed 0 
 ACK tx 305, NACK tx 1 
 ACK rx 0, NACK rx 0 

 IP address based Call Agents statistics: 
 IP address 10.48.84.25, Total msg rx 306, 
                  successful 305, failed 1 
 System resource check is DISABLED. No available statistic 

v5xxx-3#

PGW 2200 によってハングさせる呼び出しを診断して下さい

このセクションは MML コマンド rtrv tc によって方法 CIC 「x」で PGW 2200 のハングさせた SS7 CIC を隔離するためにステップを提供します: すべては PGW 2200 でように呼出しますスタックしています。 最初に、この CIC の MML prt-call コマンドを発行して下さい。

たとえば、MGCP バックホール接続で、セットアップメッセージで要求される所有者がそのコールに利用できなければ、PGW 2200 はアラーム PRI を生成します: platform.log でおよびレポート CP_ERR_CHAN_NOT_ACQ エラー使用不可能な B チャネル。 実行しているコール シナリオの種類によって platform.log に他のエラーメッセージが、現れることができます。 詳細については、PGW 2200 のための Cisco MGC ノードのトラブルシューティング資料の診断ハングさせた呼び出しセクションを参照して下さい。

入手不能のための 3 つの考えられる原因があります:

  1. 所有者は設定されません。

  2. 所有者は稼働中ではないです。 （たとえば、それはアウト オブ サービス な（OOS）状態にあります、ロックされた/ブロックされた状態にあります、または MGCP はエンドポイントをディセーブルにしました。）

  3. 所有者は使用中です（グレア状態）。

次の手順を実行します。

  1. 注場合の各コールのための PGW 2200 Reports エラー。

  2. 3 から 5 回エラーを同じ CIC （所有者）の 1日の少なくとも見れば、疑わしいです。

  3. rtrv tr の使用と CIC/bearer のステータスをチェックして下さい: 確認します。

    それがアイドル状態である場合、CIC はハングしません。

  4. SS7 CIC が使用中である場合、その CIC の prt-call コマンドを発行して下さい。

    詳細については prt コール MML コマンドで、コマンド ヘルプを発行して下さい: prt コール。

    mgc-bru-20 mml> help :prt-call
�� � � � � � � � � �MGC-01 - Media Gateway Controller 2004-11-29 19:32:35.998 GMT
� � � � � � � � � � �M� RTRV��� 
����� 
���������������������������� PRT-CALL -- Print Call
���������������������������� ----------------------
      
   Purpose:      Prints diagnostic information about hung calls to a log file.  
                 
   Format:       prt-call:<sigpath>:CIC=<n>|span=<n>[bc=<n>|CID=<n>][,LOG=<logn]
                 [,EVT]
   Input
   Description:  Target parameters are as follows:
                 * sigPath -- Corresponding MML name for any of the 
                   following component types:
                   - Signal path of in-band TDM up to MUX and then 
                     time switched to TDM media and sent to Cisco MGC
                   - Signal path of in-band TDM signaling up to CU 
                     and then encapsulated and sent over IP to the Cisco MGC

<Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>

    .prt 拡張を用いるプリント コール ファイルは /opt/CiscoMGC/var/trace ディレクトリに書かれます。

  5. ファイルを開き、ストリング LcmOrigSmState を捜して下さい。

    RelIdle として OrigSmState および TermSmState を両方見る場合、ハングさせた CIC がありません。

    例： 

    VAR LcmOrigSmState: STATE 
�� { 
�� OsmRelIdle 
�� } [8]
VAR LcmTermSmState: STATE 
�� { 
�� TsmRelIdle 
�� }[8]

    OrigSmState か TermSmState が RelIdle ではない場合、本当らしい容疑者があります。 ハングさせた CIC プリント呼び出しの 2 つの例はここにあります:

    例 1： 

    VAR LcmOrigSmState: STATE 
�� { 
�� OsmRelTerm3wAwaitConnDelInd 
�� }[8] 
VAR LcmTermSmState: STATE 
�� { 
�� TsmRelTermInit 
�� }[8]

    例 2： 

    VAR LcmOrigSmState: STATE 
�� { 
�� OsmRelOrigInit 
�� }[8] 
VAR LcmTermSmState: STATE 
�� { 
�� TsmRelIdle 
�� }[8]

    次 の ステップに達する場合、ハングさせた CIC を識別しました。

  6. ハングさせた CIC をクリアする STP コール MML コマンドを発行して下さい。

    グレップ OSM file_name.prt コマンドを発行して下さい。 OsmRelIdle を得る必要があります。

    グレップ Tsm file_name.prt コマンドを発行して下さい。 TsmRelIdle を得る必要があります。

    発行した後ない OsmRelIdle および TsmRelIdle 見るため、およびこの条件が別の prt-call コマンド（トランジェントの部分はあるように）持続すれば、CIC は多分ハングします。

  7. STP コール コマンドの問題が問題をクリアしない場合キル コール MML コマンドを発行して下さい。

    kill-call コマンドは MGCP ゲートウェイの接続をクリアしません。 従って kill-call コマンドを発行する場合、MGCP 監査が必要となります。 低いトラフィック期間の間に監査を行って下さい。 詳細については kill-call コマンドで、ヘルプを発行して下さい: kill-call コマンド:

    � �PGW2200A mml> help :kill-call
�� � � � � � � � � � �MGC-01 - Media Gateway Controller 2004-11-29 19:34:52.084 GMT
� � � � � � � � � � � M� RTRV���� 
����� 
��������������������� KILL-CALL -- Resolve a Stuck CIC
��������������������� --------------------------------
����� 
�� Purpose:����� Resolves a stuck or hung CIC (forcefully releases a bearer channel
���������������� associated with a single call instance that cannot be returned to
���������������� the idle state with the reset-cic or stp-call command) on the MGC.
���������������� Note:� This command only releases bearer channels locally on the
���������������� MGC. No SS7 messages are sent to the remote call side (destination
���������������� MGW). 
�� Syntax:������ kill-call:<sigpath_name>|<target>:CID=sip call id,confirm
���������������� kill-call:<sigpath_name>|<target>:[span= number,]confirm
���������������� kill-call:<sigpath_name>|<target>:[cic=<num>], [RNG=number,]com
���������������� kill-call:<dest_mgw>:span=<span>,bc=<bearer channel>,[RNG=numbm
�� Input�������� * sigpath_name -- MML name of the SS7 or ISDN-PRI signal path
�� Description:

<Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>

  8. サービス リクエストを Cisco テクニカル サポートで作成し、分析のために出力される prt コールを入れて下さい。

関連情報

Updated: 2006 年 2 月 02 日
Document ID: 50501

シスコ エンジニア提供

このドキュメントは役に立ちましたか?

Feedbackフィードバック

お問い合わせ先

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

このドキュメントは次の製品に対応しています

シスコについて
シスコへのお問い合わせ
採用情報