MGCP のハングしたコールでの PGW 2200 ソフトスイッチのエラー解決
Document ID: 50501
Updated: 2006 年 2 月 2 日
目次
はじめに
このドキュメントでは、Call Control Cisco PGW 2200 Softswitch ソリューションのゲートウェイでハングしたコールに関連する項目を、トラブルシューティングに役立つシナリオと組み合わせて説明します。 現在、Cisco IOS® ゲートウェイには Service Processing Elements（SPE）（『Understanding NextPort SPE Versions』で説明）をデジタル サービス 0（DS0）および Media Gateway Control Protocol（MGCP）接続に関連付ける機能はありません。 Cisco IOS デバッグがない場合、MGCP に基づくコール タイプの Cisco IOS コマンド show tdm mapping を使用して、DS0 をデジタル シグナル プロセッサ（DSP）にマッピングすることは不可能です。 Cisco Bug ID CSCdz47711（登録ユーザ専用）は、AS5350、AS5400 および AS5850 Cisco IOS ゲートウェイのこの状況を修正するために導入されています。
前提条件
要件
このドキュメントの読者は次のトピックについて理解している必要があります。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
-
Cisco PGW 2200 ソフトウェア リリース 9.3(2) および 9.4(1)
-
Cisco IOS ゲートウェイ リリース 12.3 および 12.3T
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
MGCP ハング コール エラーの解決
MGCP ハング コール シナリオが発生する場合、デバッグを使用しても解決しません。 また、ライブ システムでは、同期ペイロード エンベロープ（SPE）を DS0 および MGCP 接続に関連付けることは困難です。 アクティブ コールの DS0 および DSP を関連付ける方法について、このドキュメントでは説明しています。
最初に、PGW 2200 の MgcpBehavior の設定（マンマシン言語（MML）を使用）が Cisco IOS ゲートウェイについて 2 の値であることを確認します。 詳細については、XECfgParm.dat ファイル パラメータ ドキュメントを参照してください。
PGW 2200 バージョン 9.1(5)：
-
MgcpBehavior が 1 の場合（Cisco 音声インターワーキング サービス モジュール（VISM）および Cisco MGX などの Cisco IOS ソフトウェアに基づいていないゲートウェイ）に 501 エラーコードを受信すると、PGW 2200 は回線をそれ以上使用されない状態に設定します。 詳細については、コンポーネントとプロパティのドキュメントを参照してください。
-
MgcpBehavior が 2 の場合（Cisco IOS ゲートウェイ）に 501 エラーコードを受信すると、PGW 2200 は回線をそれ以上使用されない状態に設定します。 最初の Create Connection（CRCX）の応答で 502 エラーコードを受信した場合、PGW 2200 は MGCP Delete Connection（DLCX）を送信し、次に MGCP CRCX メッセージを送信します。 Cisco IOS ゲートウェイで別の 502 エラーコードが返されると、コールはリリースされます。 前提条件は、回線が再び使用可能になっていることです。 詳細については、コンポーネントとプロパティのドキュメントを参照してください。
PGW 2200 バージョン 9.2(2) およびそれ以降：
-
MgcpBehavior が 1 の場合（VISM および MGX）に 501 エラーコードを受信すると、PGW 2200 は回線をそれ以上使用されない状態に設定します。
-
MgcpBehavior が 2 の場合（Cisco IOS ゲートウェイ）に 501 エラーコードを受信すると、PGW 2200 は回線をそれ以上使用されない状態に設定します。 502 エラーコードを受信した場合（最初の MGCP CRCX メッセージについて）、PGW 2200 は MGCP DLCX メッセージを送信し、次に別の MGCP CRCX メッセージを送信します。 PGW 2200 が別の 502 のエラーコードを受信すると、コールはリリースされます。 回線はそれ以上使用されない状態に設定されます。 同時に、回線はバックグラウンド（mini）監査が実行される回線のリストに組み込まれます。 この監査では、mini 監査リストのすべての回線に強制 MGCP DLCX メッセージを送信して、回線ステータスを PGW 2200 と同期しようとします。
MGCP 応答のタイムアウトは、一時的な障害 GW_HELD の状態として扱われ、MGCP DLCX メッセージは毎分再試行されます。 MgcpBehavior プロパティが適切に設定されている場合、再起動中（RSIP）（正常/強制）メッセージ、MGCP エラーコード 500、501/502 のいずれかの特別なエラーコードを受信した場合にのみ、永続的なエラーが発生します。 エラーコード 500 は、「エンドポイントが不明」と同等であるため、MgcpBehavior に関係なく常に障害の原因となることに注意してください。
注: PGW 2200 リリース 9.5(2) およびそれ以降については、PGW 2200 には MGCP 1.0 が実装されています。 これにより優れた堅牢性およびエラー処理手順が提供されます。
| メッセージ | Cisco IOS ソフトウェア (5xxx) |
|---|---|
| CRCX | 502 |
| 接続を変更（MDCX） | 515 |
| DLCX | 250 |
| 通知要求（RQNT） | 400 |
| 監査エンドポイント（AUEP） | 500 |
この理由は、PGW 2200 にチャネルの状態を、Cisco IOS ゲートウェイといった通信対象のネットワーク要素と同期する監査メカニズムが搭載されているためです。 PGW 2200 の監査プログラムは、毎朝午前 4:00（0400）に、それぞれのシナリオに基づいてアクションを実行します。
-
シナリオ 1： PGW 2200 および Cisco IOS ゲートウェイのチャネルの状態がビジーの場合、アクションは実行されません。
-
シナリオ 2： PGW 2200 および Cisco IOS ゲートウェイのチャネルの状態がアイドルである場合、そのエンドポイントのために MGCP DLCX が Cisco IOS ゲートウェイに送信されます。 これにより、ハング接続が存在する場合、すべてクリアされます。
-
シナリオ 3： PGW 2200 のチャネルがビジー状態であり、Cisco IOS ゲートウェイがアイドル状態である場合、PGW 2200 はコールをリリースし、対応するエンドポイントが Cisco IOS ゲートウェイと同期するように DLCX を Cisco IOS ゲートウェイに送信します。
-
シナリオ 4： PGW 2200 のチャネルがアイドル状態であり、Cisco IOS ゲートウェイがビジー状態である場合、PGW 2200 は、対応するエンドポイントが Cisco IOS ゲートウェイと同期するように MGCP DLCX を Cisco IOS ゲートウェイに送信します。 PGW 2200 および Cisco IOS ゲートウェイの監査プロシージャにより、Cisco IOS ゲートウェイのチャネルがクリアされます。
回線をアイドル状態にするために Message Definition Language（MDL）が最初に呼び出すプロシージャが失敗する場合、MDL はエンジン インターフェイスを呼び出してエンドポイントを無効とマークし、そのエンジンの特別なハング/ストランド エンドポイント監査メカニズムに関するエントリを作成します。
Cisco IOS ゲートウェイの MgcpBehavior の値を変更するには、MGCPPATH の MgcpBehavior プロパティを 2 に変更します。
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 compact duration more ? コマンドは次に示すように Cisco IOS ゲートウェイの長時間コールを検出するのに役立ちます。
V5xxx-3# show call active voice compact duration more ? <1-2147483647> time in seconds V5xxx-3#
show call active voice brief | nclude duration 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 によって制御されるアクティブな接続に関する情報を表示します。
-
show rtpspi statistics：Real-Time Transport Protocol（RTP）サービス プロバイダー インターフェイス（SPI）統計情報を表示します。
-
show ip socket：IP ソケット情報を表示します。
-
show voice call summary：すべての音声ポートの概要を表示します。
-
show voice port summary：特定の音声ポートについての設定情報の概要を表示します。
-
show vtsp call fsm：音声テレフォニー サービス プロバイダー（VTSP）有限状態マシン（FSM）のすべての移行の全履歴を表示します。
-
show csm voice：コール スイッチング モジュール（CSM）に関する情報を表示します。 DSP チャネルに関連するコールに関して CSM 状態にあるマシン、コールの開始時間、コールの終了時間、コールに使用されるコントローラのチャネルに関する CSM の状態の情報です。
注: MGCP Signaling System 7（SS7）の場合、このコマンドはあまり役立ちません。
-
show spe：SPE のステータスを表示します。
-
show spe voice summary：SPE の音声ステータスを表示します。
-
show port operational-status slot/port（疑いのある DSP）：指定されたスロットと SPE のすべてのポートに関する情報を表示します。
-
show port voice log reverse slot/port（疑いのある DSP）：指定されたスロットと SPE のすべてのポートに関する情報を表示します。
以下に示す、一連の show コマンドの情報は、AS5xxx ゲートウェイまでの MGCP コールを参照しています。このコールの Call_ID© 情報（太字で強調されている）を含みます。 これはトラブルシューティングの際にも重要です。 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
注: MGCP モードにリンクされた M ステータスについて、Cisco PGW 2200 のミュート コールのトラブルシュートで確認してください。
show call active voice brief コマンドは送信（Tx）/受信（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#
リモート ゲートウェイの詳細を入手するには、show voip rtp connections コマンドを発行します。 これには、そのコールの 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#
show vtsp call fsm コマンドは非公開の Cisco IOS ソフトウェア コマンドであり、Cisco テクニカル サポート、および Cisco 開発チームのみが使用します。 このコマンドにより、「Invalid FSM」というエンクロージャを検索できます。 show vtsp call fsm コマンドはすべての VTSP FSM の移行の全履歴を表示します。 これは、debug vtsp error コマンドライン インターフェイス（CLI）がオンである場合に、DSP 問題が発生すると、自動的にトリガーされます。
注: CallId = 1 を 16 進数に変換して id = 0x1 とすることもできます。
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 を確認するために、コマンド show tdm mapping を発行し、トレースしているエンドポイントに詳細情報をリンクします。 この場合は、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 コマンドを（疑いのある DSP に）発行することにより、パケットが引き続きその SPE ポートで送受信されているかどうかを検出できます。
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 endpoint 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: all を使用して CIC "x" が PGW 2200 でコール アウトとしてスタックされる方法で、PGW 2200 でハング SS7 CIC を分離するステップを紹介します。 最初に、この CIC で MML コマンド prt-call を実行します。
たとえば、MGCP バックホール接続で、SETUP メッセージで要求されたベアラーがそのコールで利用できない場合、PGW 2200 はアラーム PRI: B-Channel Not Available を生成し、platform.log に CP_ERR_CHAN_NOT_ACQ エラーを報告します。 実行するコール シナリオのタイプに応じて、他のエラーメッセージが platform.log に示される可能性があります。 詳細については、PGW 2200 の Cisco MGC ノードのトラブルシューティング ドキュメントのハング コールの診断セクションを参照してください。
使用不可の原因には次の 3 つが考えられます。
-
べアラーが設定されていない。
-
べアラーがイン サービスではない。 （たとえば、アウトオブサービス（OOS）状態である、ロック/ブロック状態である、MGCP がエンドポイントを無効にしたなど）
-
べアラーはビジーである（グレア状態）。
次の手順を実行します。
-
PGW 2200 が各コールのエラーを報告する際は注意が必要です。
-
同じ CIC（ベアラー）で少なくても 1 日に 3 ～ 5 回エラーが発生する場合、ハングの疑いがあります。
-
CIC/ベアラーのステータスを確認するために rtrv-tr: 確認します。
アイドル状態であれば、CIC はハングしていません。
-
SS7 CIC がビジーの場合、CIC で prt-call コマンドを実行します。
prt-call MML コマンドの詳細については、help : prt-call コマンドを発行します。
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 ディレクトリに書き込まれます。
-
ファイルを開き、文字列 LcmOrigSmState を検索します。
OrigSmState および TermSmState の両方が RelIdle として表示される場合、ハングしている 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 が特定されています。
-
stp-call MML コマンドを発行し、ハングした CIC をクリアします。
grep Osm file_name.prt コマンドを発行します。 OsmRelIdle を取得します。
grep Tsm file_name.prt コマンドを実行します。 TsmRelIdle を取得します。
OsmRelIdle および TsmRelIdle が表示されず、別の prt-call コマンドの発行後もこの状態が継続する場合（一時的な場合もある）、CIC はハングしている可能性があります。
-
stp-call コマンドの発行で問題が解決しない場合、kill-call MML コマンドを発行します。
kill-call コマンドは、MGCP ゲートウェイ接続をクリアしません。 そのため、kill-call コマンドを発行した場合、MGCP 監査が必要になります。 監査はトラフィックが低い時間帯に実行します。 kill-call コマンドの詳細については、次に示すように help : 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>
-
Cisco テクニカル サポートによるのサービス要求を作成し、分析のために prt-call 出力を提出してください。
関連情報
このドキュメントは有用でしたか。 はい いいえ
フィードバックいただき、ありがとうございました。
ts generic='1' nval='P%1,2%%'が必要です）。Cisco サポート コミュニティ - 特集対話
Cisco サポート コミュニティでは、フォーラムに参加して情報交換することができます。
このドキュメントで使用されている表記法の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
フィードバック