debug isdn q931 コマンドを使用した ISDN BRI レイヤ 3 のトラブルシューティング

概要

ISDN コール障害の問題のトラブルシューティングを行う際は、次のいずれかがコール障害の原因となりうることを念頭に置く必要があります。

• Dial-on-Demand Routing（DDR; ダイヤルオンデマンド ルーティング）

• ISDN レイヤ 1、2、および 3

• Point-to-Point Protocol（PPP）：Link Control Protocol（LCP; リンク制御プロトコル）、認証、または IP Control Protocol（IPCP; IP 制御プロトコル）関連の問題を含む。

この文書は、コール障害を引き起こす ISDN 関連の問題に特に的を絞っています。また、このドキュメントでは、回線の両端の ISDN レイヤ 1 および 2 は正常に機能していることがすでに確認されていることを前提としています。ISDN レイヤ 1 および 2 のステータスの検証方法については、『show isdn status コマンドを使用しての BRI のトラブルシューティング』を参照してください。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

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

表記法

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

トラブルシューティングの前提条件：ISDN レイヤ 3 のデバッグの有効化

ISDN レイヤ 3 のデバッグを有効にするには、両端でコマンド debug isdn q931 を使用します。また、両方のルータでデバッグのタイムスタンプとしてミリ秒を有効にすることも必要です。タイムスタンプはトラブルシューティング プロセスに関連するデータを提供するために必要です。

注：次のコマンドを使用して、デバッグのミリ秒のタイムスタンプをアクティブにします。

maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec

debug コマンドについての詳細は、『debug コマンドの重要な情報』を参照してください。

ISDN コールの開始

リモート ルータの IP アドレスへの ICMP ping を生成します。これにより、そのルータへの ISDN コールが開始されます。どちらのルータでも、debug isdn q931 メッセージが生成されます。

ISDN スイッチ タイプに固有の要件や、追加のパラメータが必要とされるケースのために、Q.931 交換には多くのバリエーションがあります。次の図は、正常な ISDN コール設定中の一般的な Q.931 トランザクションを示しています。

注：次のデバッグ出力行の一部は、印刷用に複数の行に分割されています。

maui-soho-01#
18:39:29.425: ISDN BR0: TX -> SETUP
    pd = 8  callref = 0x10

!-- The Calling Router Transmits !-- (indicated by TX) the SETUP message

18:39:29.433:
         Bearer Capability i = 0x8890
18:39:29.441: Channel ID i = 0x83
18:39:29.449:
         Keypad Facility i = '5558888'
18:39:29.822: ISDN BR0: RX <- CALL_PROC
    pd = 8  callref = 0x90

!-- The telco switch responds with a !-- Call Proceeding. This indicates the !-- network is processing the call.

18:39:29.830:
         Channel ID i = 0x89
.
.
.

!-- Nothing has been omitted here. The !-- dots were put in place to align !-- the Called and Calling Routers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18:39:30.000: ISDN BR0: RX <- CONNECT
    pd = 8  callref = 0x90

!-- Received a CONNECT from the remote !-- router. The ISDN connection has been !-- established. Any failures of the call !-- past this point are due to higher !-- level issues such as DDR, PPP, !-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK
    pd = 8  callref = 0x10

!--- The Router responds with a Connect !--- Acknowledgment (CONNECT_ACK) !--- to the telco.

maui-nas-08#
18:39:29.647: ISDN BR2/0: RX <- SETUP
    pd = 8  callref = 0x08

!-- The Called Router receives !-- (indicated by RX) a SETUP message !-- from the switch

18:39:29.647:
    Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital. 

18:39:29.647: Channel ID i = 0x89
18:39:29.647:
    Signal i = 0x40 - Alerting on -
    pattern 0 
18:39:29.647:
    Called Party Number i = 0xC1,'5558888',
    Plan:ISDN, Type:Subscriber(local)
18:39:29.647:
    Locking Shift to Codeset 5
18:39:29.647:
    Codeset 5 IE 0x2A  
    i = 0x808001038001118001, '<'
18:39:29.651:
    ISDN BR2/0: Event: Received a DATA 
    call from  on B1 at 64 Kb/s
18:39:29.651: ISDN BR2/0: TX -> CALL_PROC
    pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding
 
18:39:29.655:
         Channel ID i = 0x89
18:39:29.655: %LINK-3-UPDOWN:
 Interface BRI2/0:1, changed state to up
18:39:29.955: ISDN BR2/0: TX -> CONNECT
    pd = 8  callref = 0x88

!--- Call is accepted and the routers sends !--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89
18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK
    pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK !--- from the switch

18:39:29.995:
         Channel ID i = 0x89
18:39:29.995:
         Signal i = 0x4F - Alerting off 
18:39:35.655: %ISDN-6-CONNECT:
 Interface BRI2/0:1 is now
 connected to unknown 

発信側および着信側で debug isdn q931 の出力を評価する際は、次の点を念頭に置いてください。

• メッセージの方向に注意してください。このデバッグでは、メッセージがルータで発生したものか（TX -> で表示）、ルータで受信されたものか（RX <-- で表示）が示されています。 次の例では、最初のメッセージ（CONNECT）は ISDN スイッチから発信され、ルータで受信されたものですが、2 番目のメッセージ（CONNECT_ACK）はルータによって送信されたものです。

  18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90
  18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10
  
  

  特定のメッセージおよび応答の方向を追跡することで、問題の根源を突き止めることができます。たとえば、ルータが電話会社の ISDN スイッチから予期せず RELEASE メッセージを受信した場合、そのルータ自体の側の接続も同様にリセットします。これは、電話会社の ISDN スイッチまたはリモート ルータに問題があることを示します。

• 受信または送信されたメッセージが期待どおりであることを確認します。たとえば、着信側が SETUP メッセージを受信しても、CONNECT の代わりに DISCONNECT を送信する場合は、ISDN ネットワークではなく、着信側ルータのトラブルシューティングを行います。次の表は、コールの確立および解放中に見られる Q.931 メッセージのリストを示しています。

トラブルシューティングの概要：症状と解決手順

前のセクションの説明に従って debug isdn q931 の出力を分析してから、次に説明の中で該当する症状に進んでください。

注：このドキュメントでは、コールを開始するルータを発信側ルータと呼び、コールを受け入れるルータを着信側ルータと呼びます。

トラブルシューティング：症状と詳細な解決手順

発信側ルータが SETUP メッセージを送信しない

発信側ルータが ISDN ネットワークに SETUP メッセージを送信しない場合、問題はおそらく ISDN レイヤ 1、2、または Dial-on-Demand Routing（DDR; ダイヤルオンデマンド ルーティング）の問題に関連しており、レイヤ 3 には関連していません。

発信側ルータで次の作業を実行します。

• ISDN スイッチタイプが正しく設定されていることを確認します。

  ISDN スイッチタイプを確認するには、コマンド show isdn status を使用します。設定を必要とするスイッチ タイプについては、電話会社から明示的な指定があるはずです。特に北米では、電話会社がスイッチ タイプとして「custom」や「national」を指定する場合があります。 その場合は、次のガイドラインに従ってスイッチ タイプの設定を決めてください。

  • Custom：電話会社から指定されたスイッチ タイプが「Custom」の場合は、ルータのスイッチ タイプを basic-5ess（5ess スイッチを使用した BRI の場合）、primary-5ess（5ess を使用した PRI の場合）、basic-dms（DMS スイッチを使用した BRI の場合）、または primary-dms（DMS を使用した PRI の場合）として設定してください。

  • National：BRI の場合は NI-1 規格、PRI の場合は NI-2 規格に準拠しているスイッチ タイプです（PRI に対する NI-1 規格はありません）。 電話会社から通知されたスイッチ タイプが「National」の場合は、Cisco ルータの設定を basic-ni（BRI の場合）または primary-ni（PRI の場合）にしてください。

  スイッチタイプを設定するには、BRI インターフェイスの設定モードで、コマンド isdn switch-type switch-type を使用します。具体例については、『ISDN BRI レイヤ 1 のトラブルシューティング』を参照してください。

• 発信側ルータの ISDN レイヤ 1 および 2 が機能していることを確認します。

  ISDN レイヤ 1 および 2 がアップしていることを確認するには、コマンド show isdn status を使用します。ISDN レイヤ 1 および 2 に関連した問題のトラブルシューティングを行う場合は、ここで説明している手順に従います。

• show ip route コマンドを使用して、ルータに宛先へのルートがあることを確認します。

  show ip route コマンドはリモート ルータ ネットワークへのルートがあるかどうかを示します。ルートが存在しない場合は、ip route コマンドを使用して、リモート ネットワーク用のスタティック ルートを追加します。スタティック ルートが発信側ルータ上の正しいインターフェイスを指していることを確認します。

  レガシー DDR 環境（ダイヤラ マップなど）では、ネクストホップは物理インターフェイス ネットワーク（interface BRI x）か、またはリモート ルータの IP アドレス（dialer map 文でも設定されている必要があります）であることが必要です。

  ダイヤラ プロファイルを使用する場合、ネクストホップは通常、ダイヤルアウトに使用される interface Dialer x です。たとえば、

  maui-soho-01#show ip route
  ...
  ...
  !-- Output omitted
  
  ...
  
       10.0.0.0/24 is subnetted, 1 subnets
  C       10.0.0.0 is directly connected, Ethernet0
  S*   0.0.0.0/0 is directly connected, Dialer1
  

  上記の例では、デフォルト ルートのネクストホップは interface Dialer 1（この接続の論理ダイヤラ インターフェイス）です。

• 対象トラフィックが正しく識別されていることを確認します。

  ルータは着信パケットが対象トラフィックであることを確認してからダイヤルを開始します。そのため、対象トラフィックが正しく定義されていない場合、または dialer-list number（対象トラフィック定義）が（dialer-group number コマンドを使用して）物理インターフェイスまたはダイヤラ インターフェイスに適用されていない場合は、ルータでのダイヤルは行われません。 たとえば、ICMP ping を使用して DDR 接続を開始しようとしている場合は、対象トラフィック定義で ICMP が許可されていることを確認します。

  詳細は、『DDR ダイヤラ マップを使用する BRI 間ダイヤルアップの設定』を参照してください。

• 該当する dialer string（または dialer map）にリモート デバイスの ISDN 番号が設定されているかどうかをチェックします。

  ダイヤラ ストリング（またはダイヤラ マップ）にはリモート ルータの ISDN 番号が設定されている必要があります。たとえば、

  dialer string 5551111
  or
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  

• DDR 設定をチェックし、debug dialer を使用してルータがコールを開始していることを確認します。

  DDR 設定が正しいことを確認します。適切な DDR 設定の詳細については、『ダイヤルアップ テクノロジー：概要と説明』ドキュメントを参照してください。

  また、コマンド debug dialer を使用して、ルータが対象トラフィックを受信していること、およびダイヤルを開始する適切なダイヤラ マップまたはダイヤラ ストリングがあることを確認します。詳細については、上記のドキュメントの他に、『ダイヤルアップ テクノロジー：詳細は、『トラブルシューティング テクニック』を参照してください。

  適切な DDR 設定の例については、次の設定例を参照してください。

  ダイヤラ プロファイル：『ダイヤラ プロファイルを使用した ISDN DDR の設定』レガシー DDR（ダイヤラ マップ）：DDR ダイヤラ マップを使用する BRI 間ダイヤルアップの設定

  ヒント：テスト目的では、DDR を削除し、代わりに isdn call コマンド（次のセクションに説明があります）を使用してリモート デバイスへの ISDN コールを生成できます。そのコールが成功する場合は、ISDN 回線が機能していると判断して差し支えありません。引き続き DDR のトラブルシューティングを行ってください。

• ループバック テスト コールを実行します。

  ループバック コールでは、ルータはそれ自体の BRI の ISDN 番号をダイヤルします。コールは電話会社のクラウドに進み、そこで電話会社によって第 2 B チャネルに切り替えられます。これにより、このコールは第 2 チャネルへの着信コールとしてルータに到達します。したがって、ルータは ISDN コールの送信と受信を両方とも行います。

  ループバック コールは、ルータが ISDN コールを開始できるか、および終端できるかをテストします。ループバック コールが成功すれば、電話会社のクラウドまでの ISDN 回線は正常に機能していると考えられます。

  次に、ループバック コールが成功した場合の注釈付き例を示します。コマンド isdn call（Cisco IOS® ソフトウェア 12.0(3)T で導入されたコマンド）では、ISDN コールを発信するために対象トラフィックやルートなどの DDR 要件が必要ありません。このコマンドは ISDN 回線をテストする目的にだけ使用できます。トラフィックを通す目的や、通常の DDR 設定の代用としては使用できません。このコマンドを使用すれば、ISDN 回線（特にレイヤ 3）が機能していることを確認できます。

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: 
Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: 
Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful

注：

• ループバック コール中、ルータは着信側ルータと発信側ルータの両方の役割を果たします（ただし、それぞれが異なる B チャネルを使用します）。 debug isdn q931 の出力を解釈する際は、これらの「デュアルロール」の経過をたどることが重要です。たとえば、ルータは SETUP メッセージを送信し（TX -> SETUP）、さらに SETUP メッセージを受信します（RX <- SETUP）。 送信された SETUP メッセージは発信コールに対応していて、受信された SETUP メッセージは着信コールに対応しています。

• 上記の例では、第 1 B チャネルの番号がダイヤルされています。電話会社では第 1 B チャネルが話中であると認識し（コールを発信しているため）、コールを第 2 B チャネルに切り替えたため、接続が正常に完了しました。しかし、電話会社スイッチの設定が誤っていて、スイッチがコールを第 1 チャネル（コールを発信しているために話中である）に割り当てようとするために、ループバック コールが失敗する場合があります。 電話会社はこの問題を修正する義務があります。ただし、回避策としてコマンド isdn call に第 2 B チャネルの番号を指定できます。

• ループバック コールが成功するのに、リモート エンドへのコールが失敗し続ける場合は、電話会社に連絡して BRI 回線のトラブルシューティングを進めてください。

着信側ルータが SETUP メッセージを受信しない

発信側ルータが ISDN レイヤ 3 の SETUP メッセージを送信していることは確認されても、着信側ルータがそのメッセージを受信していない場合、問題は着信側ルータの ISDN レイヤ 1 および 2、または 電話会社の ISDN クラウドに関係している可能性があります。

着信側ルータで次の作業を実行します。

• ISDN スイッチタイプが正しく設定されていることを確認します。

  ISDN スイッチタイプを確認するには、コマンド show isdn status を使用します。設定を必要とするスイッチ タイプについては、電話会社から明示的な指定があるはずです。特に北米では、電話会社がスイッチ タイプとして「custom」や「national」を指定する場合があります。 その場合は、次のガイドラインに従ってスイッチ タイプの設定を決めてください。

  • Custom：電話会社からスイッチタイプがCustomと表示された場合は、ルータのスイッチタイプをbasic-5ess（5essスイッチのBRIの場合）、primary-5ess（5essスイッチのPRIの場合）、basic-dms（DMSスイッチのBRIの場合）、またはprimary-dms(PRIのです。

  • National：BRI の場合は NI-1 規格、PRI の場合は NI-2 規格に準拠しているスイッチ タイプです（PRI に対する NI-1 規格はありません）。 電話会社から通知されたスイッチ タイプが「National」の場合は、Cisco ルータの設定を basic-ni（BRI の場合）または primary-ni（PRI の場合）にしてください。

  スイッチタイプを設定するには、BRI インターフェイスの設定モードで、コマンド isdn switch-type switch type を使用します。具体例については、『ISDN BRI レイヤ 1 のトラブルシューティング』を参照してください。

• 発信側ルータの ISDN レイヤ 1 および 2 が機能していることを確認します。

  ISDN レイヤ 1 および 2 がアップしていることを確認するには、コマンド show isdn status を使用します。ISDN レイヤ 1 および 2 に関連した問題のトラブルシューティングを行う場合は、『show isdn status コマンドを使用した BRI のトラブルシューティング』に記載されている手順に従います。

• SPID Local Directory Number（LDN; 市内電話番号）が正しく設定されていることを確認します。

  一部のスイッチタイプでは、着信コールを受け入れるために、SPID と LDN が正しく設定されていることが必要です。詳細については、『ISDN BRI SPID のトラブルシューティング』を参照してください。

発信側ルータで次の作業を実行します。

• 普通のアナログ電話機を使用して、リモート ルータへのテスト コールを発信します。

  普通のアナログ電話機を使用して、着信側ルータの ISDN 番号を、発信側ルータに設定されているとおりに正確にダイヤルします。着信側ルータは SETUP メッセージを受信するはずです（ただし、これは ISDN コールでないため、最終的にコールは失敗します）。 着信側ルータが SETUP メッセージを受信する場合は、着信側の ISDN ネットワークは機能していると見なすことができます。問題はローカル側の ISDN ネットワーク、宛先の ISDN 番号、長距離サービスなどに関係している可能性があります。次のステップに従います。

• 宛先の ISDN 番号が正しく設定されていることを確認します。

  発信側ルータの設定をチェックし、リモート ルータに対して設定されている ISDN 番号が正しいことを確認します。PBX の背後にある ISDN 回線では、多くの場合、ISDN 番号の先頭に 9 を付ける必要があります。また、（米国で）コールが長距離の場合は、リモート サイトの ISDN 番号の前にディジット 1 を付ける必要があります（一般電話の長距離ダイヤルと同様）。 たとえば、ローカル サイトが PBX の背後にあり、リモート サイトへのコールに長距離コールを使用する必要がある状況を考えます。リモート エンドの ISDN 番号は 5551111 で、エリア コードは 512 です。このケースでは、PBX と長距離コールに必要なディジットを付加すると、ダイヤルされる番号は 915125551111 になります。

  debug isdn q931 接続解除理由を使用して、コール障害の原因がリモート ISDN 番号の誤りにあるのか、あるいは不適切な番号の形式にあるのかも判断できます。ISDN q931 接続解除原因コードの解釈についての詳細は、ドキュメント『debug isdn q931 の接続解除原因コードの理解』を参照してください。

  次のメッセージは ISDN 番号が誤っているために接続が解除されたことを示しています。

  Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85
  Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination
  

  前述の『debug isdn q931 の接続解除原因コードの理解』を参照すれば、ISDN 以外の機器に接続しようとしたことが原因で接続解除コードが発生したことがわかります（アナログ回線など）。

  次のメッセージは番号の形式が適切でないために接続が解除されたことを示しています。

  Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
  Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format 
  (incomplete number)
  

  ドキュメント『debug isdn q931 の接続解除原因コードの理解』を参照すれば、リモート ISDN 番号の形式が無効であることが原因で接続解除コードが発生したことがわかります。つまり、接続が失敗したのは、（スイッチに対して）宛先アドレスが認識不可能な形式で提示されたか、または宛先アドレスが不完全だったからです。

• 長距離サービスがアクティブかどうかを確認します（該当する場合）。

  各地域の電話会社と長距離プロバイダーに問い合わせて、サービスがアクティブであることを確認します。各地域の電話会社の ISDN 回線に設定ミスがあり、ISDN の長距離発信コールが適切な長距離プロバイダー ネットワークに変換されないケースがよく見られます。また、長距離プロバイダー ネットワークが機能していることも確認します。

  米国では、電話会社または長距離プロバイダーが問題を解決できない場合は、Presubscribed Interexchange Carrier（PIC）を利用できます。Local Exchange Carrier（LEC; 地域の電話会社）に対して米国の長距離キャリアを明示する 7 桁のプレフィクスを PIC コードと呼びます。 お客様は PIC コードを使用することで、コールごとに異なる長距離キャリアを利用できます。PIC コードは、ダイヤル番号の接頭番号として構成されています。ほとんどの PIC は 1010xxx の形式です。PIC の番号リストについては、『US PIC codes, Numerically』 を参照してください。

• それぞれが 1 つのリモート B チャネルの ISDN 番号を持つ、それぞれのリモート B チャネルの ISDN 番号につき一つ

  リモートの B チャネルごとにダイヤラ マップ（ダイヤラ プロファイルを使用している場合はダイヤラ ストリング）を設定すると、電話会社で 2 番目のコールを ISDN の第 2 B チャネルに切り替えることができない場合でも、接続は次の段階に進みます。

  注：この回避策は、特定のBRIで1つのBチャネルだけがコールを受け入れている場合に必要です。この問題はマルチリンク接続の場合によく見られます。

  ダイヤラ マップを使用した設定例を次に示します。

  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112
  
  !--- dialer map statements for the remote router !--- The two different phone numbers correspond !--- to the b-channels of the remote side. The multiple statements allow !--- the router to dial the second number if the first number is busy. 
  
  

着信側ルータが CONNECT メッセージを送信しない

着信側ルータが SETUP メッセージを受信しているにもかかわらず、CONNECT メッセージで応答しない場合は、ルータが（なんらかの不明な理由で）コールの受け入れを拒否したことを示します。

着信側ルータで次の作業を実行します。

• 発信者 ID または DNIS ベースのスクリーニングによってコールが拒否されたのかどうかをチェックします。

  ルータは発信者 ID または DNIS ベースのスクリーニングにより、使用料を発生することなく特定のコールを選択的に受け入れまたは拒否できます。発信者 ID ベースのスクリーニングでは、着信側ルータは（SETUP メッセージによって）発信者の番号を受信します。この仕組みによってルータは特定の番号からのコールを許可できるため、セキュリティが確保されます。DNIS ベースのスクリーニングでは、着信側ルータはダイヤルされた番号に基づいて着信コールを区別します。

  CLID/DNIS ベースのスクリーニングについては、注意すべきいくつかの要点があります。

  1）電話会社により、SETUP メッセージ内に適切な CLID/DNIS 情報が提供される必要があります。ルータで発信者 ID スクリーニングが有効であるのに、発信者 ID ディジットがルータに渡されない場合は、ルータへのすべてのコールが「ふるい落とされ」、どのコールも受け入れられません。

  2）電話会社から提供されている CLID/DNIS ディジットの形式（debug isdn q931 の出力に表示されます）をチェックします。 たとえば、提供する CLID/DNIS ディジットの中にエリア コードを含める電話会社と含めない電話会社があります。それに応じて CLID/DNIS の設定を修正します。

  次に、コールが失敗した場合の例を示します。ルータでは CLID ベースのスクリーニングが有効になっていますが、電話会社から CLID ディジットが提供されていないため、ルータはコールを拒否します。

  maui-nas-08#
  05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E
  
  ! --- The router receives (RX) a SETUP message
  
  05:46:33:         Bearer Capability i = 0x8890
  05:46:33:         Channel ID i = 0x89
  05:46:33:         Signal i = 0x40 - Alerting on - pattern 0 
  05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,
    Type:Subscriber(local)
  
  ! --- The Called Number (DNIS) is delivered to the router ! --- Note that CLID information is not delivered
  
  05:46:33:         Locking Shift to Codeset 5
  05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
  05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE
  05:46:33:         Cause i = 0x8095 - Call rejected
  
  ! --- Calls is Rejected due to screening
  
  

  発信者 ID の詳細は、ドキュメント『発信者 ID を使用した ISDN の認証とコールバック』を参照してください。

• SPID が正しいことを確認します。

  show isdn status コマンドを使用して、着信側ルータの SPID が正しいことを確認します。SPID に関連した問題のトラブルシューティングについての詳細は、『show isdn status コマンドを使用した BRI のトラブルシューティング』を参照してください。

• ダイヤルされた回線上に使用可能な B チャネルがあることを確認します。

  show isdn status コマンドを使用して、ダイヤルされた回線上に使用可能なチャネルがあるかどうかをチェックします。使用可能なチャネルがない場合は、clear コマンドを使用していくつかのチャネルを解放します。

• 複数の BRI が使用可能な場合は、それらをハント グループに設定するように電話会社に依頼します。

  複数の BRI をハント グループにまとめると、電話会社で、そのルータ上の任意の空き BRI 回線にコールを切り替えることができます。この機能については、電話会社にお問い合せください。

• bearer capability に関連した問題が発生していないかどうかをチェックします。

  Bearer Capability（または bearer cap）は、特定のコールの特性を定義するレイヤ 3 サービスの属性です。コールのベアラ キャップは、Q.931 SETUP メッセージで電話会社によって指定されます。bearer cap は、64k ボイス（アナログ）、56k データ コール、および 64k データ コールを区別するためによく使用されます。最も一般的に見られる bearer cap メッセージとその説明を次に示します。

  bearer cap	説明
  0x8890	ISDN 64K コール
  0x8890218F	ISDN 56K コール
  0x8090A2	ボイス/会話コール（u-law）の場合
  0x9090A2	ボイス/会話コール（u-law）- 3.1 kHz オーディオ
  0x8090A3	ボイス/会話コール（A-law）の場合
  0x9090A3	ボイス/会話コール（A-law）- 3.1 kHz オーディオ

  次に ISDN 64k コールの例を示します。

  Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F
  
  !-- Incoming SETUP messages
  
  Aug  8 18:49:48.246:         Bearer Capability i = 0x8890
  
  !-- The bearer cap indicates the incoming call is ISDN 64k
  
  Aug  8 18:49:48.246:         Channel ID i = 0x89......
  

  コールの bearer cap に応じて、次のステップを実行します。

  Bearer Capability = 0x8890218F：コールが ISDN 56K デジタルの場合：

  • ISDN スイッチタイプが正しく設定されていることを確認します。

    ISDN スイッチタイプを確認するには、コマンド show isdn status を使用します。設定を必要とするスイッチ タイプについては、電話会社から明示的な指定があるはずです。特に北米では、電話会社がスイッチ タイプとして「custom」や「national」を指定する場合があります。 その場合は、次のガイドラインに従ってスイッチ タイプの設定を決めてください。

    • Custom：電話会社からスイッチタイプがCustomと表示された場合は、ルータのスイッチタイプをbasic-5ess（5essスイッチのBRIの場合）、primary-5ess（5essスイッチのPRIの場合）、basic-dms（DMSスイッチのBRIの場合）、またはprimary-dms(PRIのです。

    • National：BRI の場合は NI-1 規格、PRI の場合は NI-2 規格に準拠しているスイッチ タイプです（PRI に対する NI-1 規格はありません）。 電話会社から通知されたスイッチ タイプが「National」の場合は、Cisco ルータの設定を basic-ni（BRI の場合）または primary-ni（PRI の場合）にしてください。

    スイッチタイプを設定するには、BRI インターフェイスの設定モードで、コマンド isdn switch-type switch type を使用します。具体例については、『ISDN BRI レイヤ 1 のトラブルシューティング』を参照してください。

  • 発信側で、コールの速度/レートが 56k であることを確認します。これが必要であるのは、レガシー ISDN スイッチによっては、クリアーなチャネルを通すことができないので、通過するコールの速度を 56K にするように強制する場合があるためです。

    発信コールを 56 Kbps にするには、次の例のように、dialer map 設定コマンドで speed パラメータを使用します。

    maui-soho-01(config)#interface bri 0
    maui-soho-01(config-if)#dialer map ip 10.1.1.1 name 
    Maui-NAS-08 speed 56 5551111
    
    !-- The keyword speed 56 sets the outgoing call rate at 56k
    
    

    次の例は、Cisco IOS ダイヤラ プロファイルで発信コールの速度を 56 Kbps に設定する方法を示しています。

    maui-soho-01(config)#interface dialer 1
    maui-soho-01(config-if)#dialer string 5558888 class 56k     
    
    !-- Use the map-class named "56k" when dialing number 5558888 
               
    maui-soho-01(config-if)#exit
    maui-soho-01(config)#map-class dialer 56k
    
    !-- map-class named "56k" that was used with the dialer string above
    
    maui-soho-01(config-map-clas)#dialer isdn speed 56
    
    !-- Set the speed of the call to be 56k (default is 64k)
    
    

  • 着信側では、BRI インターフェイスでコマンド isdn not-end-to-end 56 を設定します。

    Maui-NAS-08(config)#interface bri 2/0
    Maui-NAS-08(config-if)#isdn not-end-to-end 56
    

    ISDN Q.931 bearer capability とその他の Information Element（IE; 情報要素）は着信コールの速度を判断するために使用され、ほとんどの環境で正常に動作します。しかし、他国との間の実装では（または一部のレガシー スイッチが原因で）、発信コールと一致しない bearer capability を含む着信コール設定メッセージが提供される場合があります。ISDN が「エンドツーエンドでない」ことを示すメッセージが受信された場合、ルータは Cisco IOS 設定コマンド isdn not end-to-end を使用して、受信された bearer capability を上書きできます。

    Bearer Capability = 0x8090A2 または 0x9090A2：ボイス/会話コール（u-law）の場合

    Bearer Capability = 0x8090A3 または 0x9090A3：ボイス/会話コール（A-law）の場合

    着信コールは 64k アナログ コールです。モデム アプリケーションでは、コールは内部モデムに送信されます。ボイス アプリケーションでは、コールは適切な音声モジュールに送信される場合があります。次のステップを実行します。

    1. 着信側で、ISDN 物理インターフェイス（interface bri 0 など）に isdn incoming-voice modem が設定されていることを確認します。

    2. モデム回線にコマンド modem inout が設定されていることを確認します。

    設定例については、ドキュメント『Cisco 3640 BRI を使用したモデム接続の設定』を参照してください。

  • DISCONNECT メッセージまたは RELEASE メッセージによって（着信側ルータから発信側ルータへ）送信された接続解除原因コードを解釈します。

    着信側ルータは、発信側ルータに CONNECT メッセージを送信しない場合、DISCONNECT メッセージまたは RELEASE メッセージを送り返します。この DISCONNECT メッセージまたは RELEASE メッセージにも、接続解除原因コードが含まれています。次の例では、接続解除原因コードは0x8090です。接続解除コードを解釈するには、ドキュメント『debug isdn q931接続解除原因コードについて』を参照してください。

    Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8  
    callref = 0x06
    Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing
    

発信側ルータが CONNECT メッセージを受信しない

着信側ルータが CONNECT メッセージを送信しているにもかかわらず、そのメッセージが発信側ルータで受信されない場合、問題はおそらく電話会社にあります。

• ルータがローカル ISDN スイッチから CONNECT_ACK を受信しているかどうかを確認します。

  これは、着信側ルータの近くに位置する電話会社スイッチが CONNECT メッセージを受け入れ、発信側ルータに CONNECT メッセージを渡していることを示します。このコール障害はおそらく電話会社の問題です。

• これ以上のトラブルシューティングについては、電話会社に連絡してください。

発信側ルータは CONNECT を受信しているが、それでもコールが失敗する

発信側ルータが CONNECT メッセージを受信している場合は、ISDN 接続はアクティブで、正常に機能していることを示します。電話会社に問い合せて、B チャネルがデータに対してエンドツーエンドで正しくマップされていない問題が起こっているかどうかを確認します。この段階よりも後になんらかのコール障害が発生した場合、その原因は PPP、認証、IPCP/IP アドレスのネゴシエーションなど、上位層の問題にあります。さらに PPP のトラブルシューティングを行う場合は、debug ppp negotiation を使用します。

PPP のトラブルシューティング テクニックの詳細は、『ダイヤルアップ テクノロジー：トラブルシューティング テクニック』も参照してください。

関連情報

• アクセス テクノロジーのサポート
• テクニカルサポート - Cisco Systems

更新履歴