Cisco IOS 音声デジタル（T1/E1）を装備したインターフェイスにおけるダイヤルイン方式（DID）について

ダウンロードオプション

PDF (303.7 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (93.1 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (105.4 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2006 年 2 月 2 日

Document ID:14072

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

前提条件

要件

使用するコンポーネント

表記法

背景説明

POTS ダイヤルピアの DID 設定

DID 用の正しい着信 POTS ダイヤルピアの照合

ケーススタディ

コンフィギュレーション

一般的な問題

show および debug の出力例

概要

このテクニカルノートは、デジタルインターフェイス（T1/E1）を装備した Cisco IOS 音声対応ルータ/ゲートウェイを対象にしています。 Cisco アナログダイヤルイン方式（DID）の詳細については、次のドキュメントを参照してください。Cisco 2600 および Cisco 3600 シリーズルータのアナログ DID

注：ほとんどのプラットフォームでは、CAS（即時、ウィンク、遅延）インターフェイスでDIDがデフォルトで有効になっています。そのため、着信コールに対しては direct-inward-dial コマンドを設定しないでください。Cisco AS5300 プラットフォームでは、DID は E&M イミディエートシグナリング用に設定されたインターフェイス上ではサポートされません。

前提条件

要件

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

使用するコンポーネント

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

表記法

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

背景説明

DID は、発信者が、オペレータや自動化されたコールアテンダントの支援を得ることなく、構内交換機（PBX）またはパケット音声システムの内線に直接ダイヤルできる、電話会社から提供されるサービスです。このサービスは、電話番号の末尾 3 ～ 5 桁のみを PBX またはルータ/ゲートウェイに転送する DID トランクを使用します。たとえば、ある企業が電話の内線番号 555-1000 から 555-1999 までを所有しており、発信者が 555-1234 をダイヤルした場合、ローカルの中央オフィス（CO）は 234 を PBX またはパケット音声システムに転送します。PBXまたはパケット音声システム（Cisco CallManagerおよびIOSルータ/ゲートウェイ）は、内線234を呼び出します。このプロセス全体は、発信者に対して透過的です。

このドキュメントでは、次の 2 種類のダイヤルピアについて説明します。

Plain Old Telephone Service（POTS; 一般電話サービス）：これは、コールの最中に専用 64K 回線エンドツーエンドコールレッグを得る、Public Switched Telephone Network（PSTN; 公衆電話交換網）経由で行われる従来の音声コールです。POTS ダイヤルピアは、常にルータの音声ポートをポイントします。
音声ネットワーク：データネットワーク上の音声コールは、複数のコールレッグで構成されています。各コールレッグは、データデバイス間（ルータやゲートウェイ）、またはデータデバイスとテレフォニーデバイス間（ルータから PBX までなど）のいずれかを通過します。音声ネットワークダイヤルピアは、使用されるネットワークテクノロジーに応じて、異なる接続先をポイントします。音声ネットワークダイヤルピアには、次のようなものがあります。
- Voice over IP（VoIP）
- Voice over Frame Relay（VoFR）
- Voice over ATM（VoATM）
- Multimedia Mail over IP（MMoIP）

音声コールが Cisco IOS ルータ/ゲートウェイに到達すると、ルータの音声ポートは、PBX または CO スイッチによって着信用に捕捉されます。その後、ルータ/ゲートウェイは発信者にダイヤルトーンを返し、発信ダイヤルピアを特定できるようになるまでディジットを収集します。ディジットが、人間により不規則な間隔でダイヤルされるとしても、収集前ディジットを送信する電話機器により定期間隔でダイヤルされるとしても、ダイヤルピアの照合はディジットごとに行われます。これは、ルータ/ゲートウェイが、各ディジットが受信された後にダイヤルピアを照合することを意味しています。このプロセスを 2 段階ダイヤリングと呼びます。

ただし、PBX または CO スイッチがコールを完全にルーティングするために必要な「すべての」ディジットを含む設定メッセージを送信した場合、それらのディジットは発信音声ネットワークダイヤルピアに直接マップできます。DID では、ルータ/ゲートウェイは発信者に発信音を返さず、ディジットも収集しません。コールは設定された宛先に直接転送されます。これを 1 段階ダイヤリングと呼びます。

上述のコールのルーティングに必要なディジットには、次の 2 つのタイプがあります。

着信番号情報サービス（DNIS）は、呼び出し先番号（ダイヤルされた番号）を通知する、電話会社が提供するデジタルサービスです。
自動番号識別（AN）は、呼び出し元番号（発信元の番号）を通知する、電話会社が提供するデジタルサービスです。ANI は、発信側回線 ID（CLID）とも呼ばれます。

POTS ダイヤルピアの DID 設定

単純な旧式の電話サービス（POTS）インターフェイスからの着信コールを受け取ると、ダイヤルピアの DID 機能によって、ルータ/ゲートウェイは、着信者番号（DNIS）を発信ダイヤルピアと直接照合できるようになります。DID が着信 POTS ダイヤルピアで設定されると、着信者番号が自動的に使用されて、発信コールレッグの接続先パターンが照合されます。

DID 用の POTS ダイヤルピアを設定するには、まずグローバル設定モードで、次の Cisco IOS コマンドを入力します。

Router(config)#dial-peer voice number pots		
Router(config-dial-peer)#direct-inward-dial

DID 用の正しい着信 POTS ダイヤルピアの照合

DID が正常に機能するように、着信コールが、direct-inward-dial コマンドが設定されている正しい POTS ダイヤルピアと一致することを確認します。正しい着信ダイヤルピアと照合するために、DID POTS ダイヤルピアの下でダイヤルピアコマンド incoming called-number dnis_stringを使用することをお勧めします。

ダイヤルピアのマッチングに使用されるその他のコマンドには、次のものがあります。answer-address ani_string、destination-pattern string、または port voice-port 。incoming called-number コマンドを使用するメリットは、すべてのコールには関連する DNIS 情報（着信者番号）があり、前に示すコマンドよりも優先順位が高いということです。

着信ダイヤルピアを照合するために incoming called-number コマンドを使用しない場合は、次を考慮する必要があります。

ANI 情報を使用して DID POTS ダイヤルピアと照合する場合、answer-address コマンドが正しく設定されており、電話会社のスイッチが ANI 情報を提供していることを確認します。一部の ISDN プロバイダーと、ほとんどの T1 個別線信号方式（CAS）（Feature Group D（fgd）を除く）は、ANI 情報を提供しません。
answer-address が ANI と照合されない場合、ANI は別の POTS ダイヤルピアの下で（発信ダイヤリング用に）設定された destination-pattern と照合されている可能性があります。destination-pattern が ANI と照合される場合、direct-inward-dial コマンドがそのダイヤルピアの下で設定されていることを確認します。
incoming called-number、answer-address、destination-pattern、または port のいずれかを基準としても、着信した DID コールが着信 POTS ダイヤルピアと一致しない場合、デフォルトのダイヤルピア 0 が使用されます。デフォルトでは DID は、ダイヤルピア 0 上では無効になっています。

ケーススタディ

次の例を使用して、前述のポイントを例示します。ACME 社には、555-3100 から 555-3139 までの範囲の 40 個の DID トランクを含む T1 PRI 回線があります。目標は、最初の 20 回線を Cisco IP Phone に割り当てることです。残りの 20 回線はテストと将来の拡張のために使用し、現時点では、ルータは発信音のみを返します。CO スイッチが ISDN 設定メッセージ内の下 5 桁だけを送信していると仮定し、前述の情報をまとめると、次の表のようになります。

PSTN ユーザのダイヤル	スイッチによって音声ルータ/ゲートウェイに送信される番号	利用	トランク数
555-3100 ～ 555-3119	53100 ～ 53119	IP Phone 用の DID 回線	20
555-3120 ～ 555-3139	53120 ～ 53139	テストと将来の拡張	20

コンフィギュレーション

注：この例の出力の一部は省略されています。

dial-peer voice 2 pots 
        destination-pattern 9T 
        port 1/0:23

 !--- This dial-peer is used mainly for outbound dialing with the !--- destination-pattern 9T mapped to port 1/0:23. Note that 9 is an !--- explicit match and will be stripped. Say a call comes from the CallManager !--- with a DNIS 914085551126, the router will send only 14085551126. If you add !--- the dial-peer command prefix 9 or the command forward-digit all then !--- the string 914085551126 is sent. Notice that dial-peer voice 2 pots is also !--- matched to give dial tone to incoming users dialing this range: !--- (53120 - 53139).

     dial-peer voice 3 pots 

 !--This dial-peer can be matched inbound only

      incoming called-number 5310.  

 !--DNIS range 53100-53109 

      direct-inward-dial  

 !--If this dial-peer is matched inbound, the router is put in DID mode

     !
     dial-peer voice 4 pots 

 !--This dial-peer can be matched inbound only

      incoming called-number 5311.   

 !--This takes care of the range 53110-53119

      direct-inward-dial 

 !--If this dial-peer is matched inbound router is put in DID mode

     !
     dial-peer voice 5 voip  

 !--For our case, this dial-peer is matched outbound only 

      destination-pattern 53... 

 !--When calls terminate on this router, dial-peer 5 can be matched inbound, too.

      session target ipv4:172.22.1.1 

 !--IP address of CallManager

      codec g711ulaw

一般的な問題

注：接続解断原因コードは、debug voip ccapi inoutコマンドとは異なり、debug isdn q931の出力に異なる形式があります。

debug voip ccapi inout からの Q.931 コール切断原因コードを解釈するには、次のドキュメントを参照してください。VoIP コールのトラブルシューティングとデバッグ - 基本
debug isdn q931 からの Q.931 コール切断原因コードを解釈するには、次のドキュメントを参照してください。debug isdn q931 の接続解除原因コードについて

10 進数形式で Q.931 イベント原因コードを確認するには、次のドキュメントを参照してください。ISDN イベント原因コード

次に、いくつかの症状の例と、その症状を引き起こす可能性のある問題を示します。

症状：ルータ/ゲートウェイがダイヤルトーンを出し、ディジット間タイマーがタイムアウトするまで待機します。それから、debug voip ccapi inout 原因コード = 0x1C（無効な番号形式）、または debug isdn q931（ISDN インターフェイス用）切断原因コード = 0x809C（無効な番号形式）で接続を切断します。
- 問題：DID は、電話会社スイッチには設定されますが、Cisco IOS ルータ/ゲートウェイには設定されません。
症状：ルータ/ゲートウェイが、debug voip ccapi inout 原因コード = 0x1（未割り当て/未指定番号）、または debug isdn q931（ISDN インターフェイス用）切断原因コード = 0x8081（未割り当て/未指定番号）で接続を切断します。
- 問題：DID が設定されており、正しい着信 POTS ダイヤルピアが Cisco IOS ルータ/ゲートウェイで照合されましたが、設定メッセージに着信者番号（DNIS）が含まれていません。この場合、トランクが DID 用にプロビジョニングされていることを電話会社に問い合わせて確認してください。
症状：ルータ/ゲートウェイが、debug voip ccapi inout 原因コード = 0x1（未割り当て/未指定番号）または debug isdn q931（ISDN インターフェイス用）接続解除原因コード = 0x8081（未割り当て/未指定番号）で接続を解除します。
- 問題：DID が設定され、Cisco IOS ルータ/ゲートウェイで照合されましたが、ルータ/ゲートウェイで発信ダイヤルピアの照合がありません。
- 問題：着信コールが、direct-inward-dial コマンドが設定されている正しい POTS ダイヤルピアに一致していることを確認します。詳細については、このドキュメントの「DID 用の正しい着信 POTS ダイヤルピアの照合」セクションを参照してください。

show および debug の出力例

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

2600#debug isdn q931
ISDN Q931 packets debugging is on
2600#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on

2600#show debug
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 31
  1 - - - - - - -  - - - - - - - -  - - - - - - - -  - - - - - - - -  
voip:
  voip ccAPI function enter/exit debugging is on


!--- Action: Cisco IOS router/gateway receives a call from the PSTN to !--- extension "53103"

*Mar  1 04:51:11.856: ISDN Se1/0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Mar  1 04:51:11.860:         Bearer Capability i = 0x9090A2
*Mar  1 04:51:11.860:         Channel ID i = 0xA98381
*Mar  1 04:51:11.864:         Calling Party Number i = 0x0083, '408', Plan:Unknown,
      Type:Unknown
*Mar  1 04:51:11.868:         Called Party Number i = 0x80, '53103', Plan:Unknown,
      Type:Unknown

!--- ISDN Q.931 and Voip ccapi inout debugs collectively show a DNIS of 53103 and !--- an ANI (Automatic Number Identification) of 408 sent in unknown plan and type.


*Mar  1 04:51:11.880: cc_api_call_setup_ind (vdbPtr=0x831721D8, callInfo=
        {called=53103,called_oct3=0x80,calling=408,calling_oct3=0x0,
        calling_oct3a=0x83, calling_xlated=false,subscriber_type_str=RegularLine,
        fdest=1,peer_tag=3, prog_ind=0},callID=0x83349DF8)
*Mar  1 04:51:11.884: cc_API_call_setup_ind type 13 , prot 0
*Mar  1 04:51:11.888: cc_process_call_setup_ind (event=0x83149130)
*Mar  1 04:51:11.888: >>>>CCAPI handed cid 41 with tag 3 to app "DEFAULT"

!--- POTS dial-peer 3 was matched inbound


*Mar  1 04:51:11.888: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(41), disp(0)
*Mar  1 04:51:11.888: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(41), disp(0)
*Mar  1 04:51:11.888: ssaCallSetupInd 
*Mar  1 04:51:11.892: ccCallSetContext (callID=0x29, context=0x83303C00)

!--- The POTS leg is created and assigned a callid of 0x29


*Mar  1 04:51:11.892: ssaCallSetupInd cid(41), st(SSA_CS_MAPPING),oldst(0), 
      ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
*Mar  1 04:51:11.892: ssaCallSetupInd finalDest cllng(408), clled(53103)

!--- Due to the direct-inward-dial config under dial-peer 3, the DNIS sent in !--- the setup request is considered sufficient to match an outbound dial-peer. !--- This is clear with flag set to 1. 


*Mar  1 04:51:11.892: ssaCallSetupInd cid(41), st(SSA_CS_CALL_SETTING),oldst(0),
      ev(24)dpMatchPeersMoreArg result= 0
*Mar  1 04:51:11.892: ssaSetupPeer cid(41) peer list:  tag(5) called number (53103) 

!--- Dial-peer table lists only dial-peer 5 as matched outbound against the DNIS.


*Mar  1 04:51:11.892: ssaSetupPeer cid(41), destPat(53103), matched(2), 
      prefix(), peer(83369DB8), peer->encapType (2)

!--- Due to destination-pattern having 2 digits and 3 dots, explicit match is !--- reported as 2.


*Mar  1 04:51:11.896: ccCallProceeding (callID=0x29, prog_ind=0x0)
*Mar  1 04:51:11.896: ccCallSetupRequest (Inbound call = 0x29, outbound peer =5,
      dest=, params=0x831578C0 mode=0, *callID=0x83157C28, prog_ind = 0)
*Mar  1 04:51:11.896: ccCallSetupRequest numbering_type 0x80
*Mar  1 04:51:11.896: dest pattern 53..., called 53103, digit_strip 0
*Mar  1 04:51:11.896: callingNumber=408, calledNumber=53103, redirectNumber=
      display_info= calling_oct3a=83

!--- Just before matching an outbound dial-peer, we remember that we have !--- seen the same ANI and DNIS in the ISDN setup and in the ccapi debug initially. !--- In other words, the router did not collect additional digits after the seizure. !--- Equal value of DNIS at setup request and before matching an outbound !--- dial-peer is the whole purpose of DID


*Mar  1 04:51:11.896: accountNumber=, finalDestFlag=1,
      guid=c66d.980c.17a8.0051.0000.0000.010a.998a
*Mar  1 04:51:11.896: peer_tag=5
*Mar  1 04:51:11.896: ccIFCallSetupRequestPrivate: (vdbPtr=0x824C6344, dest=, 
      callParams={called=53103,called_oct3=0x80, calling=408,calling_oct3=0x0, 
      calling_xlated=false,subscriber_type_str=RegularLine, fdest=1,
      voice_peer_tag=5},mode=0x0) vdbPtr type = 3
*Mar  1 04:51:11.900: ccIFCallSetupRequestPrivate: (vdbPtr=0x824C6344, dest=,
      callParams={called=53103, called_oct3 0x80,  calling=408,calling_oct3 0x0, 
      calling_xlated=false,  fdest=1, voice_peer_tag=5}, mode=0x0, xltrc=-5)
*Mar  1 04:51:11.900: ccSaveDialpeerTag (callID=0x29, dialpeer_tag=
*Mar  1 04:51:11.900: ccCallSetContext (callID=0x2A, context=0x8330408C)
*Mar  1 04:51:11.900: ccCallReportDigits (callID=0x29, enable=0x0)
*Mar  1 04:51:11.904: cc_API_call_report_digits_done (vdbPtr=0x831721D8,
      callID=0x29, disp=0)
*Mar  1 04:51:11.904: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE),
      cid(41), disp(0)
*Mar  1 04:51:11.904: cid(41)st(SSA_CS_CALL_SETTING)ev
      (SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)
.

!--- Output Omitted

.

!--- The following output displays the Call is finished


*Mar  1 04:51:52.442: ISDN Se1/0:23: RX <-  DISCONNECT pd = 8  callref = 0x0001
*Mar  1 04:51:52.442:         Cause i = 0x8290 - Normal call clearing
*Mar  1 04:51:52.458: ISDN Se1/0:23: TX ->  RELEASE pd = 8  callref = 0x8001
*Mar  1 04:51:52.458: cc_API_call_disconnected(vdbPtr=0x831721D8, callID=0x29,
      cause=0x10)
*Mar  1 04:51:52.462: sess_appl: ev(11=CC_EV_CALL_DISCONNECTED), cid(41), disp(0)
*Mar  1 04:51:52.462: cid(41)st(SSA_CS_ACTIVE)ev(SSA_EV_CALL_DISCONNECTED)
      oldst(SSA_CS_ACTIVE)cfid(9)csize(2)in(1)fDest(1)
*Mar  1 04:51:52.462: -cid2(42)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 04:51:52.462: ssa: Disconnected cid(41) state(5) cause(0x10)
*Mar  1 04:51:52.462: ccConferenceDestroy (confID=0x9, tag=0x0)
*Mar  1 04:51:52.462: cc_API_bridge_drop_done (confID=0x9, srcIF=0x824C6344, 
      srcCallID=0x2A, dstCallID=0x29, disposition=0 tag=0x0)
*Mar  1 04:51:52.466: cc_API_bridge_drop_done (confID=0x9, srcIF=0x831721D8, 
      srcCallID=0x29, dstCallID=0x2A, disposition=0 tag=0x0)
*Mar  1 04:51:52.466: sess_appl: ev(30=CC_EV_CONF_DESTROY_DONE), cid(41), disp(0)
*Mar  1 04:51:52.470: cid(41)st(SSA_CS_CONF_DESTROYING)ev(SSA_EV_CONF_DESTROY_DONE)
      oldst(SSA_CS_ACTIVE)cfid(-1)csize(2)in(1)fDest(1)
*Mar  1 04:51:52.470: -cid2(42)st2(SSA_CS_CONF_DESTROYING)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 04:51:52.470: ssaConfDestroyDone 
*Mar  1 04:51:52.470: ccCallDisconnect (callID=0x29, cause=0x10 tag=0x0)
*Mar  1 04:51:52.470: ccCallDisconnect (callID=0x2A, cause=0x10 tag=0x0)


!--- These two lines are great for finding the source of the disconnect. !--- They tell us that the first call leg with callid 0x29 (POTS call leg) !--- disconnected with cause code 0x10. So either the end POTS user hung up or the !--- telephony equipment disconnected unintentionally. From the router's point of !--- view, both are the same.


*Mar  1 04:51:52.470: ISDN Se1/0:23: RX <-  RELEASE_COMP pd = 8  callref = 0x0001
*Mar  1 04:51:52.499: cc_API_call_disconnect_done(vdbPtr=0x831721D8, callID=0x29,
      disp=0, tag=0x0)


!--- Debug truncated here
 


2600#show call active voice brief 

!--- This show command is good to verify which are the dial-peers matched by the !--- call. In the example below, the output show the POTS call-leg matched !--- dial-peer voice 3 pots (pid:3) the VoIP call-leg matched !--- dial-peer voice 5 voip (pid:5). !--- some output omitted


Total call-legs: 2
3A   : 799622hs.1 +112 pid:3 Answer 408 active
 dur 00:00:07 tx:385/61600 rx:160/23690
 Tele 1/0:23:33: TX:7730/3060/0ms g711ulaw noise:-42 acom:0  i/0:-43/-53 dBm

3A   : 799625hs.1 +106 pid:5 Originate 53103 active
 dur 00:00:07 TX:160/23690 rx:385/61600
 IP 171.68.168.250:25704 rtt:0ms pl:4980/0ms lost:0/0/0 delay:64/64/65ms g711ulaw

Cisco IOS 音声デジタル（T1/E1）を装備したインターフェイスにおけるダイヤルイン方式（DID）について

ダウンロードオプション

偏向のない言語

翻訳について

内容

概要

前提条件

要件

使用するコンポーネント

表記法

背景説明

POTS ダイヤルピアの DID 設定

DID 用の正しい着信 POTS ダイヤルピアの照合

ケーススタディ

コンフィギュレーション

一般的な問題

show および debug の出力例

関連情報

このドキュメントは役に立ちましたか?

シスコに問い合わせ

Cisco IOS 音声デジタル（T1/E1）を装備したインターフェイスにおけるダイヤルイン方式（DID）について

ダウンロード オプション

偏向のない言語

翻訳について

内容

このドキュメントは役に立ちましたか?

シスコに問い合わせ

ダウンロードオプション