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

はじめに

このドキュメントでは、デジタルインターフェイス(T1/E1)を備えたCisco IOS®音声対応ルータ/ゲートウェイについて説明します。 Cisco アナログ Direct Inward Dialing（DID; ダイヤルイン方式）の詳細については、「Analog DID for Cisco 2600 and Cisco 3600 Series Routers」を参照してください。

注：ほとんどのプラットフォームでは、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 が使用されます。ダイヤルピア 0 では、DID はデフォルトで無効になっています。

ケース スタディ

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

コンフィギュレーション

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

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（未割り当て/未指定番号）で接続を解除します。

  • 問題：Cisco IOS ルータ/ゲートウェイでは DID が設定されており、適切なインバウン ド POTS ダイヤルピアにマッチしていますが、セットアップメッセージに着信番号（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