内容

概要

前提条件

要件

使用するコンポーネント

表記法

MGCP ハング コール エラーの解決

show コマンド

PGW 2200 ハング コールの診断

関連情報

概要

このドキュメントでは、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 メディア ゲートウェイ コントローラ ソフトウェア リリース 9 のドキュメンテーション

- Cisco メディア ゲートウェイ コントローラ ソフトウェア リリース 9.3(2) のリリース ノート

- Cisco Media Gateway Controller ソフトウェア リリース 9.4(1) のリリース ノート

使用するコンポーネント

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

- 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時に実行されます。(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 コマンドはアウトプット インタープリタ ツールによってサポートされています（登録ユーザ専用）。このツールを使用することによって、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 | include 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

注：Cisco PGW 2200のミュートコールのトラブルシューティングでMGCPモードにリンクされているMステータスを確認します。

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を使用してPGW 2200上でコールOUTとしてスタックする方法で、ハングしたSS7 CICをPGW 2200上で分離する手順を説明します。最初に、この 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 つが考えられます。

1. べアラーが設定されていない。

2. べアラーがイン サービスではない。（たとえば、アウトオブサービス（OOS）状態である、ロック/ブロック状態である、MGCP がエンドポイントを無効にしたなど）

3. べアラーはビジーである（グレア状態）。

次のステップを実行します。

1. PGW 2200 が各コールのエラーを報告する際は注意が必要です。

2. 同じ CIC（ベアラー）で少なくても 1 日に 3 ～ 5 回エラーが発生する場合、ハングの疑いがあります。

3. rtrv-tr:all MMLコマンドを使用して、CIC/ベアラのステータスを確認します。

アイドル状態であれば、CIC はハングしていません。

4. 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 ディレクトリに書き込まれます。

5. ファイルを開き、文字列 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 が特定されています。

6. stp-call MML コマンドを発行し、ハングした CIC をクリアします。

grep Osm file_name.prt コマンドを発行します。OsmRelIdle を取得します。

grep Tsm file_name.prt コマンドを実行します。TsmRelIdle を取得します。

OsmRelIdle および TsmRelIdle が表示されず、別の prt-call コマンドの発行後もこの状態が継続する場合（一時的な場合もある）、CIC はハングしている可能性があります。

7. 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>

8. Cisco テクニカル サポートによるのサービス要求を作成し、分析のために prt-call 出力を提出してください。

関連情報

- Cisco PGW 2200 ソフトスイッチ トラブルシューティング テクニカル ノート

- Cisco シグナリング コントローラの製品サポート

- 音声に関する技術サポート

- 音声と IP 通信製品サポート

- Cisco IP Telephony のトラブルシューティング

- テクニカル サポートとドキュメント – Cisco Systems