この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、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 ハング コール シナリオが発生する場合、デバッグを使用しても解決しません。また、ライブ システムでは、同期ペイロード エンベロープ(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 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#
このセクションでは、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 つが考えられます。
べアラーが設定されていない。
べアラーがイン サービスではない。(たとえば、アウトオブサービス(OOS)状態である、ロック/ブロック状態である、MGCP がエンドポイントを無効にしたなど)
べアラーはビジーである(グレア状態)。
次のステップを実行します。
PGW 2200 が各コールのエラーを報告する際は注意が必要です。
同じ CIC(ベアラー)で少なくても 1 日に 3 ~ 5 回エラーが発生する場合、ハングの疑いがあります。
rtrv-tr:all MMLコマンドを使用して、CIC/ベアラのステータスを確認します。
アイドル状態であれば、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 出力を提出してください。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
02-Feb-2006 |
初版 |