NTT ISDN 使用時における Dialer の発信制限について（Rev. Nov 5, 2010）

目次

• 概要
• 前提条件
  • 要件
  • 使用するコンポーネント
  • 本ドキュメントにおいて対象となる構成および状況
  • 表記法
• debug dialer について
• 発信制限を確認する方法
• 発信制限の規定と Cisco 製品での実装について
  • 発信制限の規定
  • Cisco 製品での実装
• 関連資料

---

概要

BRI、PRI インターフェースを使用したダイヤルアップ接続（DDR 接続）において、日本国内で使用する ISDN スイッチタイプが NTT の場合には、再発呼動作に対し発信制限があります。このドキュメントでは、トラブルシュートを行う際に、最初に陥りやすく、トラブルシューティングの妨げになりやすい、電気通信事業法の規定による発信制限についてまとめております。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• ISDN に関する基礎知識
• DDR（Legacy dialer および Dialer Profile）に関する基礎知識

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありませんが、IOS が動作し BRI や PRI（チャネライズド T1）インターフェースを持つルータプロダクトを対象としております。

本ドキュメントにおいて対象となる構成および状況

• DDR（Legacy dialer および Dialer profile）構成による ISDN 接続で、日本国内における標準的な NTT INS-64サービス、NTT INS-1500サービスを使用した接続の場合
• 発呼しない事象が発生し、回線側の問題であるかを確認するトラブルシューティングを実施する場合

表記法

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

debug dialer について

ISDN BRI インターフェースや PRI インターフェースを使用し、ダイヤルアップ接続を行う際、発信しない問題の多くは、debug コマンドで失敗の理由が確認できる場合があります。以下がトラブルシューティングに役立つ一般的な debug コマンドとなります。

• debug dialer
• debug isdn event
• debug isdn q921
• debug isdn q931
• debug ppp negotiation

この中で、debug dialer は、ダイヤルアップのトラブルシューティングにおける初動調査において最も有益な debug となります。まず、debug dialer を取得することで、発信が失敗する理由が、後述します 電気通信事業法の規定による発信制限ではないことを確認し、その上で、適切なトラブルシューティングを実施する必要があります。

発信制限を確認する方法

ISDN BRI インターフェース、PRI インターフェースを使用し、NTT の提供する INS-64、INS-1500サービスを利用する上では、スイッチタイプを NTT（isdn switch-type ntt、isdn switch-type primary-ntt）に設定する必要があります。

Cisco ルータでは、スイッチタイプを NTT に設定した場合、電気通信事業法の規定に伴い、同一電話番号への再発信が3分間に2回に制限されます。発信が失敗する理由がこの制限によるものであるかを確認するためには、発信時に debug dialer をセットし、Attempting to dial メッセージの後に、以下のメッセージの出力があるかどうかを確認する必要があります。

BR0/0 DDR: Attempting to dial XXXXXX
BRI0/0: call delayed. number redialed too soon

このメッセージが出力されている場合、電気通信事業法の規定による発信制限となります。よって、これは短時間のうちに同一の電話番号へ再発呼を試みている結果となります。根本事象である再発呼の原因を正しく確認する上では、この 電気通信事業法の規定が解除されるまで待つ必要があります（数分〜3分程度）。その上で、各種 debug を再度取得し、ISDN レイヤにてエラーの有無や切断理由を確認する必要があります。再発呼の原因となっている根本原因をトラブルシュートする上では、後述の関連資料のリンクを参照してください。

発信制限の規定と Cisco 製品での実装について

発信制限の規定

ISDN 通信設備（総合デジタル通信用設備）における同一電話番号への再発信制限の規定は、電気通信事業法の規定に基づく端末設備等規則、第六章 第三十四条の三に記載されております。

Cisco 製品での実装

現行の Cisco 製品の動作では、JATE の発信制限である3分に2回の制限を守るために、90秒間に1回のみの再発信が許可されます。これは、同一宛先の電話番号で、かつ、その失敗が ISDN レイヤにおける発信の失敗であった場合が対象となります。

ISDN レイヤの失敗となる条件は、ISDN レイヤに関するプロセスでのエラーや切断が主な原因となります。主な原因は、以下のとおりです。

• ISDN レイヤ1の問題
  ケーブル抜けや、モジュールや DSU、ケーブルの故障等の問題により、ISDN レイヤ1をアクティブにできない場合。
• ISDN レイヤ2（Q.921）の問題
  交換機までの接続や交換機との Q.921のセットアップに問題があり、TEI をアサインできず、ISDN レイヤ2をアクティブにできない場合。
• ISDN レイヤ3（Q.931）の問題
  回線網側の問題や障害、話中や相手側で接続できる回線や空き B チャネルがない場合、また、Caller ID セキュリティや ISDN sub-address のミスマッチ等により、Q.931 の切断要求（DISCONNECT メッセージ）を受け取り接続が失敗した場合。
• その他、モジュールや IOS の不具合により、ISDN プロセスがエラーを返す場合。

これらの多くは、debug isdn event、debug isdn q921、debug isdn q931 を取得し、後述の関連資料のリンクを参照することにより、その原因が特定できる場合があります。ただし、ISDN レイヤ3（Q.931）の問題である場合には、debug isdn q931 により出力される切断理由の Cause 情報を確認してください。Cause 情報が、以下のような Normal call clearing の場合、これは通話後に受話器を置いた状態と同じであり、接続の失敗を意味しません。

ISDN BR0/0/0 Q931: RX <- DISCONNECT pd = 8  callref = 0x86
        Cause i = 0x8090 - Normal call clearing

よって、この場合には、発信の失敗として判断されることはありません。ISDN レイヤ3に問題があり、発信制限がかかる場合には、これ以外の Cause 情報を対向側から受け取ることが想定されます。

また、以下の場合においても、ISDN レイヤにおける発信の失敗として判断されることはありませんので注意が必要です。

• 発呼する interface が shutdown 状態である場合
  この場合、dialer プロセスが、使用できる dialer のメンバーがいないと判断するため、ISDN プロセスのエラーとはならず ISDN レイヤの失敗とはなりません。ただし、前述のとおり、ケーブル抜けによる、interface down は、ISDN プロセスのエラーとなり、ISDN レイヤの失敗となります。
• CHAP 認証の失敗など、PPP ネゴシエーションフェーズにおける失敗の場合
  この場合、一度 ISDN コールは確立しているため、ISDN プロセスではエラーを受け取りません。PPP ネゴシエーションフェーズのエラーは、ISDNレ イヤの失敗とはなりません。この場合、ISDN プロセスでは、Q.931の DISCONNECT メッセージを Normal call clearing で受け取る点に注意が必要です。

---

関連情報

• ダイヤルアップ テクノロジー：トラブルシューティング テクニック
• show isdn status コマンドを使用した BRI のトラブルシューティング
• ISDN BRI レイヤ1のトラブルシューティング
• トラブルシューティング：BRI レイヤ2
• debug isdn q931 コマンドを使用した ISDN BRI レイヤ3のトラブルシューティング
• debug isdn q931 の接続解除原因コードの理解
• T1 PRI に関するトラブルシューティング
• T1アラームに関するトラブルシューティング