音声 : テレフォニー シグナリング

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

2010 年 10 月 8 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 2 月 2 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
背景説明
POTS ダイヤル ピア用の DID 設定
DID 用の正しい着信 POTS ダイヤル ピアの照合
事例
設定方法
一般的な問題
show と debug の出力例
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

このテクニカル ノートは、デジタル インターフェイス(T1/E1)を備えた Cisco IOS 音声対応ルータ/ゲートウェイに適用できます。Cisco アナログ Direct Inward Dialing(DID; ダイヤルイン)の詳細については、次のドキュメントを参照してください。『Cisco 2600 および Cisco 3600 シリーズ ルータのアナログ DID』

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

前提条件

要件

このドキュメントに関する特別な要件はありません。



使用するコンポーネント

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



表記法

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



背景説明

DID は、発信者が、オペレータや自動化されたコール アテンダントの支援を得ることなく、Private Branch Exchange(PBX; 構内交換機)またはパケット音声システムの内線に直接ダイヤルできる、電話会社から提供されるサービスです。このサービスは DID トランクを利用しており、これが、電話番号の下 3 桁から 5 桁までだけを、PBX またはルータ/ゲートウェイに転送します。たとえば、ある企業が電話の内線番号 555-1000 から 555-1999 までを所有しており、発信者が 555-1234 をダイヤルした場合、ローカルの Central Office(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; マルチメディア メール オーバー IP)

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

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

前の段落で説明したコールをルーティングするために必要なディジットは、次の 2 つのタイプになります。

  • Dialed Number Identification Service(DNIS; 着信番号情報サービス)は、呼び出された番号(ダイヤルされた番号)を配信する電話会社によって提供されるデジタル サービスです。

  • Automatic Number Identifier(ANI; 自動番号識別)は、呼び出し側の番号(コール オリジネーターの番号)を配信する電話会社によって提供されるデジタル サービスです。ANI は、Calling Line Identification(CLID)とも呼ばれています。



POTS ダイヤル ピア用の DID 設定

Plain Old Telephone Service(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_stringdestination-pattern string、または port voice-port があります。incoming called-number コマンドを使用するメリットは、すべてのコールには関連する DNIS 情報(着番号)があり、その前のコマンドよりも優先度があることです。

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

  • ANI 情報を使用して DID POTS ダイヤル ピアと照合する場合、answer-address コマンドが正しく設定されて、電話会社のスイッチが ANI 情報を提供していることを確認します。いくつかの ISDN プロバイダーと、Feature Group D(fgd)を除くほとんどの T1 Channel Associated Signaling(CAS; 個別線信号方式)は、ANI 情報を提供しません。

  • answer-address が ANI と照合されない場合、ANI は別の POTS ダイヤル ピアの下で(発信ダイヤリングのために)設定された destination-pattern と照合されている可能性があります。destination-pattern が ANI と照合される場合、direct-inward-dial コマンドがそのダイヤル ピアの下で設定されていることを確認します。

  • 着信 DID コールが incoming called-numberanswer-addressdestination-patternport のいずれかに基づいた着信 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

callmanager-gw.gif



設定方法

注:この例の出力のいくつかは省略されています。

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


     !--- このダイヤル ピアは、ポート 1/0:23 にマップされた宛先パターン 9T で 
!--- 主に発信ダイヤリングのために使用されます。9 は明示的な照合であり、 
!--- 削除されることに注意してください。あるコールが DNIS 914085551126 の CallManager
!--- からのものであるとすると、ルータは 14085551126 だけを送信します。ダイヤル ピア コマンド 
!--- prefix 9 またはコマンド forward-digit all を追加した場合、 
!--- 文字列 914085551126 が送信されます。dial-peer voice 2 pots も照合されて、
!--- この範囲(53120 〜 53139)をダイヤルしている着信ユーザにダイヤル トーンを提供します。
 
dial-peer voice 3 pots 


     !--このダイヤル ピアは、着信専用の DNIS 範囲
incoming called-number 5310.  


     !--53100 〜 53109 に照合できます。
direct-inward-dial  


     !--このダイヤル ピアが着信で照合される場合、ルータは DID モードになります。
!
     dial-peer voice 4 pots 


     !--このダイヤル ピアは、着信だけに照合します。
incoming called-number 5311.   


     !--これは、範囲 53110 〜 53119 を扱います。
direct-inward-dial 


     !--このダイヤル ピアが着信で照合される場合、ルータは DID  モードになります。
!
     dial-peer voice 5 voip  


     !--この場合は、このダイヤル ピアは発信だけに照合されます。
destination-pattern 53... 


     !--このルータでコールが終了すると、ダイヤル ピア5 は着信にも照合できます。
session target ipv4:172.22.1.1 


     !--CallManager の IP アドレス
codec g711ulaw 


一般的な問題

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

10 進数形式で Q.931 イベント原因コードを確認するには、『ISDN event cause codes leavingcisco.com』を参照してください。

次に示すのは、現象の例とその原因と見なされる問題です。

  • 症状:ルータ/ゲートウェイがダイヤル トーンを提供し、ディジット間タイマーがタイムアウトするまで待機します。次に、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



!--- アクション:Cisco IOS ルータ/ゲートウェイは PSTN から内線番号「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 と Voip ccapi 入力デバッグは、53103 の DNIS と未知の計画と種別で送信された、408 の  
!--- Automatic Number Identification(ANI; 自動番号識別)を全体で表示します。
*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 ダイヤル ピア 3 は着信と照合されました。
*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)


!--- POTS レッグが作成され、0x29 の callid を割り当てられます。
*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)


!--- dial-peer 3 の下での direct-inward-dial 設定によって、設定要求で送信された DNIS は 
!--- 発信 dial-peer に照合するのに十分であると見なされます。 
!--- これは、フラグが 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) 


!--- ダイヤル ピア テーブルは、DNIS に対して照合された発信として dial-peer 5 だけをリストします。
*Mar  1 04:51:11.892: ssaSetupPeer cid(41), destPat(53103), matched(2), 
      prefix(), peer(83369DB8), peer->encapType (2)


!--- 2 つのディジットと 3 つのドットを持つ宛先パターンがあるので、明示的な照合は
!--- 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


!--- 発信ダイヤル ピアを照合する直前に、ISDN 設定と ccapi デバッグの初期に 
!--- 同じ ANI と DNIS を確認したことを思い出しました。 
!--- いいかえると、ルータは起動後は追加のディジットを収集しませんでした。 
!--- 設定要求時と発信ダイヤル ピアを照合する前の DNIS の等価の値は 
!--- 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)
.


!--- 出力を省略。
.


!--- 次の出力はコールが終了したことを示しています。
*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)



!--- この 2 行は接続解除の発信元を見つけるのに最適です。 
!--- これらによって、callid 0x29(POTS  コール レッグ)の最初のコール レッグが、
!--- 原因コード 0x10 で接続解除されていることがわかります。したがって、終端 POTS でユーザが通話を終了したか、
!--- 電話機器が意図せず接続を解除されたかのいずれかが発生します。ルータからすると、
!--- どちらも同じことです。
*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)



!--- ここでのデバッグを省略
2600#show call active voice brief 


!--- この show コマンドは、コールによってどれが照合されたダイヤル ピアであるのかを確認するのに 
!--- 適切です。次の例では、出力は POTS コール レッグが照合されたことを示します。
!--- dial-peer voice 3 pots(pid:3)VoIP コール レッグが照合されました。 
!--- dial-peer voice 5 voip(pid:5)

!--- 出力を一部省略
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



関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 14072