内容

概要

前提条件

要件

使用するコンポーネント

表記法

PRI バックホール解決策の説明

トラブルシュート

ステップ 1：Cisco Gateway AS5xx0 設定の検査

ステップ 2：PGW 2200 設定の検査

ステップ 3：AS5xx0 と PGW 2200 の間の RUDPV1 およびセッション マネージャ リンクの検査

ステップ 4：AS5xx0 と PABX の間の Q.921 ステータスの検査

関連情報

概要

このドキュメントでは、コール制御モードの Cisco PGW 2200 での PRI バックホールに関するトラブルシューティング情報を提供します。プロトコル ファミリの違いによって、バックホーリングはいくつかのカテゴリに分けられます。たとえば、ISDN Q シグナリング（QSIG）および Digital Private Network Signaling System（DPNSS）です。

このドキュメントでは、Cisco PGW 2200 を使用した PRI バックホールのみを取り上げます。

前提条件

要件

このドキュメントの読者は次のトピックについての専門知識を有している必要があります。

- Cisco メディア ゲートウェイ コントローラ ソフトウェア リリース 9

使用するコンポーネント

このドキュメントの情報は、Cisco PGW 2200 ソフトウェア リリース 9.3(2) 以降に基づいています。

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

表記法

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

PRI バックホール解決策の説明

PRI/Q.931 シグナリング バックホールは、PRI トランクからのシグナリング（Q.931 以上のレイヤ）を確実に伝送する機能です（図 1 を参照）。 この PRI トランクは、処理用にメディア ゲートウェイ コントローラ（MGC - Cisco PGW 2200）に接続しているメディア ゲートウェイに物理的に接続されます。ISDN PRI のシグナリング バックホールは、レイヤ 2（Q.921）とレイヤ 3（Q.931）の境界で発生します。プロトコルの下位レイヤはメディア ゲートウェイ（AS5xx0）で終端し、処理されるのに対して、上位レイヤは Cisco PGW 2200 にバックホールされます。

プロトコルの上位レイヤは、IP 経由の Reliable User Datagram Protocol（RUDP）を使用して Cisco PGW 2200 にバックホールまたは伝送されます。RUDP は、接続されたセッションと失敗したセッションの自律通知を提供し、順序に従う確実なシグナリング プロトコル配信を IP ネットワーク全体で提供します。バックホール セッション マネージャは、RUDP セッションを管理する Cisco PGW 2200 上およびメディア ゲートウェイ上のソフトウェア機能です。シグナリング バックホールは、分散プロトコル処理の追加的なメリットを提供します。これにより、拡張性とスケーラビリティが向上します。また、Cisco PGW 2200 から下位レイヤ プロトコル処理がオフロードされます。レイヤ モデルから、PRI バックホールは IP/UDP/RUDP/Backhaul-Session-Manager/PRI ISDN レイヤ 3 に構築されます。

図 1：PRI バックホール

図 2：PRI バックホール - コール セットアップ シーケンス

図 3：PRI バックホール - コール セットアップ シーケンス

図 4：PRI バックホール - コール クリア

トラブルシュート

PRI バックホールをトラブルシュートするには、次の手順を実行します。

- ステップ 1：Cisco Gateway AS5xx0 設定を検査します。

- ステップ 2：Cisco PGW 2200 設定を検査します。

- ステップ 3：Cisco AS5xx0 と Cisco PGW 2200 の間のセッション マネージャ リンクを検査します。

- ステップ 4：AS5400 と PABX の間の Q.921 ステータスを検査します。

ステップ 1：Cisco Gateway AS5xx0 設定の検査

ゲートウェイ設定を検査するには、次の手順を実行します。

1. IOS® エラー メッセージ「% BSM:Session is not created, max limit exceeded You can support maximum of 16 session in IOS gateway 5xx0.」が表示されたら、Cisco PGW 2200 と対話するようにバックホール セッション マネージャをセットアップするために、グローバル コンフィギュレーション モードで次のコマンドを発行します。

backhaul-session-manager

set set1

group group1 set set1

session group group1 x.x.x.x x.x.x.x port priority

このコマンドの出力例を示します。

backhaul-session-manager

set pgw-cag client nft

group pgw-cag set pgw-cag

session group pgw-cag 213.254.253.140 6000 213.254.252.5 6000 1

session group pgw-cag 213.254.253.141 6000 213.254.252.5 6000 2

session group pgw-cag 213.254.253.156 6000 213.254.252.21 6000 3

session group pgw-cag 213.254.253.157 6000 213.254.252.21 6000 4

注：異なる物理PGW 2200をポイントするセッションを同じグループに配置するためにバックホールセッションマネージャ(BSM)設定を使用する場合、Cisco IOSの設定はサポートされません。2 つの PGW 2200 を 2 つのグループに分離する必要があります。詳細については、Cisco Bug ID CSCec24132 を参照してください。

2. pri-group timeslots 1-31 service mgcp コマンドを入力して、コントローラ設定の下で PRI バックホーリング用にコントローラをセットアップします。

以下に、いくつかの例を示します。

controller E1 7/5

pri-group timeslots 1-31 service mgcp

注：この設定例では、後でCisco PGW 2200の設定に反映されるコントローラE1 7/5を使用しています。

3. バックホール セッション マネージャへの ISDN レイヤ 2 インターフェイスにリンクするために ISDN D チャネル設定の下で isdn bind-l3 backhaul xxxx コマンドを挿入します。

以下に、いくつかの例を示します。

!

interface Serial7/5:15

no ip address

isdn switch-type primary-net5

isdn protocol-emulate network

isdn incoming-voice modem

isdn bind-l3 backhaul pgw-cag

isdn PROGRESS-instead-of-ALERTING

no isdn outgoing display-ie

isdn outgoing ie redirecting-number

isdn incoming alerting add-PI

no cdp enable

注：isdn negotiate-bchan resend-setup cause code 41を追加すると、発信コールにのみ適用され、ルータが受信したコールには適用されません。この CLI は EXCLUSIVE インジケータなしでセットアップを送信し、使用可能な別の B チャネルが存在する場合にはスイッチがそれを選択できるようにします。そうでない場合、スイッチが原因コード 41 を伴って応答するときに、ルータが別の B チャネルを選択してセットアップを再び送信します。

注：スイッチに、セットアップメッセージの特性に一致するBチャネルがない可能性があります。この場合、スイッチは別の B チャネルを割り当てることができず、優先される別の B チャネルを使ったセットアップもまた失敗します。

注：コントローラでMGCP NASとPRIバックホールを同時に使用することはできません。（MGCP NAS に必須の）E1 コントローラ上の extsig mgcp コマンドは、コントローラ上の pri-group の設定を防止します。

as5400(config)#contro e1 7/0

as5400(config-controller)#extsig mgcp

as5400(config-controller)#pri-group service mgcp

%Default time-slot= 16 in use

4. バックホールするセッション マネージャをデバッグするには、debug backhaul-session-manager コマンドを発行します。

ステップ 2：PGW 2200 設定の検査

PGW 2200 設定を検査するには、次の手順を実行します。

1. IPFASPATH を Cisco PGW 2200 設定に追加します。

prov-add:IPFASPATH:NAME="pri2-sig",DESC="Signalling PRI2

withCommunicationNAS02",EXTNODE="NAS02",MDO="ETS_300_102",

CUSTGRPID="Cisco1",SIDE="network",ABFLAG="n",CRLEN=2

これにより、MDO バリアントが IOS ゲートウェイ バリアントと確実に同等になります。

注：この表に含まれるISDNバリアントを確認します。

2. DCHAN を Cisco PGW 2200 設定に追加します。

prov-add:DCHAN:NAME="pri2-dch1",DESC="Dchannel PRI2 to

Project Communication",SVC="pri2-sig",PRI=1,SESSIONSET=

"mil1-pri2-ses",SIGSLOT=7,SIGPORT=5

これにより、SigSlot/SigPort が確実に指定されます。また、シスコ ゲートウェイ ポート/スロットと Cisco PGW 2200 ポートが DCHAN 上で確実に一致します。

注：IOSゲートウェイでisdn bind-l3 backhaul IOSコマンドを含むE1 7/5コントローラを使用する場合は、MML DCHANコマンドのSIGSLOT=7,SIGPORT=5を同じ情報にする必要があります。

3. スイッチド トランクをプロビジョニングする際、SPAN パラメータを決して 0 にしないでください。 export_trunk.dat ファイルの 3 列目の内容からこれを確認できます。

SPAN 値は、スイッチド トランクでは ffff にする必要があります。これを確認するには、MMLコマンドラインからprov-exp:all:dirname="file_name"コマンドを発行します。

mgcusr@pgw2200-1% mml

Copyright © 1998-2002, Cisco Systems, Inc.

Session 1 is in use, using session 2

pgw2200-1mml> prov-exp:all:dirname="check1"

MGC-01 - Media Gateway Controller 2005-08-12 17:39:44.209 MEST

M  RTRV

"ALL"

;

pgw2200-1 mml> quit

/opt/CiscoMGC/etc/cust_specific/check1 ディレクトリに移動します。export_trunk.dat ファイルで、3 列目に 0 ではなく ffff が含まれていることを確認します。 そうでない場合、ファイルを編集して修正します。

4. prov-add:files:name="BCFile",file="export_trunk.dat",action="Import"コマンドを発行してMMLプロビジョニングセッションを開始し、トランクファイルを再インポートします。

変更された export_trunk.dat ファイルは /opt/CiscoMGC/etc/cust_specific/check1 ディレクトリの下にあります。新しい設定を有効にするために prov-cpy を発行することを忘れないでください。

5. 現在発生しているエラーのタイプを説明するには、MML コマンドの rtrv-alms を発行します。

rtrv-dest:all

!--- Shows the MGCP connectivity status of nodes !--- that the PGW 2200 defines.

rtrv-dchan:all

!--- On the active PGW 2200, the status is !--- pri-1:ipfas-1,LID=0:IS. On the standby PGW 2200, !--- the status is pri-1:ipfas-1,LID=0:OOS,STBY.

rtrv-iplnk:all

!--- All of the iplnk are on the standby PGW 2200 in the !--- iplnk-1:OOS,STBY status. They are actually in !--- the OOS state because no message is handled by them. !--- On the active PGW 2200, you see the status as iplnk-1:IS. !--- The other statuses are explained in the !--- MML Command Reference Chapter of the Cisco MGC Software !--- MML Command Reference Guide.

rtrv-tc:all

!--- Shows the status of all call channels.

rtrv-alms::cont

!--- Check the Alarms status on the Cisco PGW 2200.

また、perlコマンドperl -F, -anwe 'print unpack("x4 A15", localtime($F[1])),".$F[2]:@F[0,3..7]"' < meas.csv を使用して、/opt/CiscoMGC/var/log から alm.csv ファイルの詳細を取得することもできます。

注：UTCタイムスタンプに変換する場合は、localtimeではなくgmtimeを使用してください。出力は次の形式で表示されます。

Aug 10 15:58:53.946: 0 0 1 "Fail to communicate with peer module

over link B" "ipAddrPeerB" "ProvObjManagement"

Aug 10 21:29:30.934: 0 1 1 "Provisioning: Dynamic Reconfiguration"

"POM-01" "ProvObjManagement"

Aug 10 21:29:48.990: 0 1 2 "Signal Channel Failure" "c7iplnk1-ls-stp1" "IosChanMgr"

Aug 10 21:29:49.620: 0 0 2 "Non-specific Failure" "ls-stp1" "IosChanMgr"

Aug 10 21:29:49.620: 0 0 2 "Signal Channel Failure" "c7iplnk1-ls-stp1" "IosChanMgr"

Aug 10 21:29:49.630: 0 0 2 "SS7 Signaling Service Unavailable" "srv-bru8" "IosChanMgr"

6. ディレクトリ /opt/CiscoMGC/var/log で platform.log を検査するには、UNIX コマンド tail -f platform.log を発行します。

詳細については、『ログ メッセージ』を参照してください。

7. ISDN バリアントを検査します。

IOS ゲートウェイ上で isdn switch-type primary-net5 コマンドを使用します。Cisco PGW 2200 では、これは IPFASPATH 内の mdo=ETS_300_102 にリンクされています。

次の表に、Cisco PGW 2200 でサポートされている ISDN バリアントを示します。

バリアント名

ISDNPRI

仕様

備考

ETS_300_102

ISDNPRI

ETSI 300_102

ETSI PRI

ETS_300_102_C2

ISDNPRI

ETSI 300_102

ETSI PRI

ATT_41459

ISDNPRI

AT&T 41459

ATT ISDN PRI

ATT_41459_C2

ISDNPRI

（Nortel Meridian）

Cisco AT&T PRI

ETS_300_172

ISDNPRI

ETSI 300-172

ETSI QSIG

Q931_AUSTRALIA

ISDNPRI

Q931

オーストラリア PRI

Q931

ISDNPRI

Q931

Q931

Q931_SINGAPORE

ISDNPRI

Q931

シンガポール PRI

これは IOS ゲートウェイからのサンプル コマンド出力です。

v5350-3(config)#isdn switch-type ?

primary-4ess    Lucent 4ESS switch type for the U.S.

primary-5ess    Lucent 5ESS switch type for the U.S.

primary-dms100  Northern Telecom DMS-100 switch type for U.S.

primary-net5    NET5 switch type for UK, Europe, Asia , Australia

primary-ni      National ISDN Switch type for the U.S.

primary-ntt     NTT switch type for Japan

primary-qsig    QSIG switch type

primary-ts014   TS014 switch type for Australia (obsolete)

v5350-3(config)#

ステップ 3：AS5xx0 と PGW 2200 の間の RUDPV1 およびセッション マネージャ リンクの検査

RUDPV1 とセッション マネージャ リンクを検査するには、次の手順を実行します。

1. 次の show and clear コマンドを発行します。

- show rudpv1 failure:rudpv1が検出した障害を表示します。たとえば、SendWindowFullFailures と表示された場合は、IP リンク上で送出されるセグメントが輻輳していることを示します。

- show rudpv1 parameters:rudpv1接続パラメータ、および現在のすべてのセッションの状態とパラメータを表示します。接続タイプは ACTIVE と PASSIVE のどちらかです。ACTIVE は、このピアがクライアントで、接続を開始したことを示します。PASSIVE は、このピアがサーバで、接続をリッスンしたことを示します。

- show rudpv1 statistics:rudpv1の内部統計情報、現在のすべてのセッションの統計情報、および最後にボックスをリブートした後またはclear statisticsコマンドを実行した後のすべてのrudp接続の累積統計情報を表示します。

- clear rudpv1 statistics：収集されたすべてのrudpv1統計情報をクリアします。最新の統計情報が必要で、IOS ゲートウェイが長期間動作している場合には、いつでもこのコマンドを実行できます。

2. debug rudpv1 コマンドを発行します。

#debug rudpv1 ?

application  Enable application debugging

client       Create client test process

performance  Enable performance debugging

retransmit   Enable retransmit/softreset debugging

segment      Enable segment debugging

server       Create server test process

signal       Show signals sent to applications

state        Show state transitions

timer        Enable timer debugging

transfer     Show transfer state information

ライブ システムでは、パフォーマンス、状態、信号、および転送のデバッグが最も役立ちます。アプリケーション、再伝送、およびタイマーのデバッグでは、大量の出力が生成されてリンク障害が発生したり、内部デバッグにしか役に立たなかったりします。

注意：このデdebugコマンドは、送受信されるセグメントごとに1行ずつ出力します。大量のトラフィックが流れている場合は、これによりタイミングが遅れて、リンク障害が発生します。

3. show backhaul-session-manager コマンドと show backhaul set all コマンドを発行して、シグナリングを伝送する IP パイプが正常かどうかを確認します。

NAS02#show backhaul-session-manager group status all

Session-Group

Group Name   : pgw-cag

Set Name     : pgw-cag

Status       : Group-Inservice

Status (use) : Group-Active

NAS02#show backhaul  set all

Session-Set

Name   : pgw-cag

State  : BSM_SET_ACTIVE_IS

Mode   : Non-Fault-Tolerant(NFT)

Option : Option-Client

Groups : 1

statistics

Successful switchovers:0

Switchover Failures: 0

Set Down Count 1

Group: pgw-cag

show backhaul set all コマンドのさまざまなステータスを以下に示します。

- BSM_SET_IDLE

- BSM_SET_OOS

- BSM_SET_STDBY_IS

- BSM_SET_ACTIVE_IS

- BSM_SET_FULL_IS

- BSM_SET_SWITCH_OVER

- BSM_SET_UNKNOWN

さらに、すべてが正常な場合は、Cisco PGW 2200 上の対応するセッション セットリンクがインサービス ステータスであることも分かります（mml コマンド rtrv-iplnk）。 これで、Cisco PGW 2200 と IOS ゲートウェイ AC5xx0 の間のパイプが完全に機能していることを確認できました。次のステップは、Cisco IOS ゲートウェイ AS5xx0 と PABX の間の境界を検査することです。

ステップ 4：AS5xx0 と PABX の間の Q.921 ステータスの検査

AS5xx0 と PABX の間の Q.921 ステータスを確認するには、次の手順を実行します。

1. show isdn status コマンドと show isdn service コマンドを発行します。

NAS02#show isdn status

Global ISDN Switchtype = primary-net5

ISDN Serial7/5:15 interface

******* Network side configuration *******

dsl 0, interface ISDN Switchtype = primary-net5

L2 Protocol = Q.921  L3 Protocol(s) = BACKHAUL

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0xFFFF7FFF

Number of L2 Discards = 4, L2 Session ID = 25

Total Allocated ISDN CCBs = 0

NAS02#show isdn service

PRI Channel Statistics:

ISDN Se7/5:15, Channel [1-31]

Configured Isdn Interface (dsl) 0

Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)

Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Service State (0=Inservice 1=Maint 2=Outofservice)

Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

これで、Q.921 が起動しない問題が、PGW 2200 側で宛先および非稼働状態のままの D チャネルに対応していることが分かり始めます。最初に可能性があるのは、Q.921 ネットワーク側の設定の不一致です。これが問題の原因でないことは簡単にわかります。なぜなら、AS5400 設定から isdn protocol-emulate network を削除しても問題が解決されなかったからです。

2. Q.921 デバッグを参照して、Q.921 リンクが起動しない理由を確認します。これがデバッグ出力です。

Apr 14 10:57:23.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0

Apr 14 10:57:24.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0

Apr 14 10:57:25.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0

Apr 14 10:57:45.419: ISDN Se7/5:15 Q921: Net RX <- BAD FRAME(0x02017F)

Apr 14 10:57:46.419: ISDN Se7/5:15 Q921: Net RX <- BAD FRAME(0x02017F)

AS5400 は Q.921 SABME を伝送してリンクを初期化し、解釈できなかったフレーム（不良フレーム）を受信します。 次のような可能性があります。

- この AS5400 用の E1 でのハードウェアの問題。

- リモート側の E1 ループ。

- リモート側のハードウェアまたは設定の問題。

この最初の可能性は、同じAS5400上の別の未使用のE1に設定を移動することによって除外されます。問題はまったく同じに見えます。また、E1にループがないことも確認します。この時点で、PABX側を確認します。

3. show controller コマンドを発行して、レイヤ 1 エラーの可能性を検査します。

#show controllers E1

Framing is CRC4, Line Code is HDB3, Clock Source is Line.

Data in current interval (480 seconds elapsed):

107543277 Line Code Violations, 0 Path Code Violations

120 Slip Secs, 480 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 480 Unavail Secs

Total Data (last 24 hours)

3630889 Line Code Violations, 4097 Path Code Violations,

2345 Slip Secs, 86316 Fr Loss Secs, 20980 Line Err Secs, 0 Degraded Mins,

1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 86317 Unavail Secs

4. コントローラで shutdown コマンドを発行すると、結果として次のデバッグ メッセージが生成されます。

000046: Jun 2 16:19:16.740: %CSM-5-PRI: delete PRI at slot 7, unit 2, channel 0

000047: Jun  2 16:19:16.744: %CONTROLLER-5-UPDOWN: Controller E1 7/2, changed sn

000048: Jun  2 16:19:16.744: SESSION: PKT: xmt. (34) bufp: 0x6367F52C, len: 16

PGW 2200 上で MML コマンド rtrv-alms を発行します。

mml> rtrv-alms

MGC-02 - Media Gateway Controller 2005-06-02 18:11:29.285 GMT

M  RTRV                                                                                                                                                                                                                            "pri-bucegi: 2005-06-02 17:28:15.301 GMT,ALM=\"FAIL\",SEV=MJ"

コントローラで no shutdown コマンドを発行すると、結果として IOS ゲートウェイで次のデバッグ メッセージが生成されます。

000138: Jun  2 17:03:25.350: %CONTROLLER-5-UPDOWN: Controller E1 7/2, changed sp

000139: Jun  2 17:03:25.350: %CSM-5-PRI: add PRI at slot 7, unit 2, channel 15 0

この他の IOS debug コマンドについては、『コール エージェント アプリケーションの PRI/Q.931 シグナリング バックホール』を参照してください。

関連情報

- Cisco PGW 2200 ソフトスイッチ テクニカル ノート

- Cisco シグナリング コントローラの技術文書

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

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

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

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