IOS Voice Digital(T1/E1) 인터페이스의 DID(Direct-Inward-Dial) 이해

이 문서는 자체 게시 워크플로로 마이그레이션되었습니다. 이 문서는 원래 https://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html에 게시되었습니다.
이 문서는 현재 지침에 맞게 업데이트해야 하며 게시하기 전에 이 메모를 제거해야 합니다. 이 문서를 미리 보기 위해 게시할 때 문서 ID가 14072 있고 URL이 이 단락에 있는 원래 URL과 일치하는지 확인합니다. 문서 ID 또는 URL이 일치하지 않으면 tz-writers@cisco.com으로 문의하십시오.

소개

이 문서에서는 디지털 인터페이스(T1/E1)가 있는 Cisco IOS® 음성 지원 라우터/게이트웨이에 대해 설명합니다. Cisco DID(Analog Direct Inward Dialing)에 대한 자세한 내용은 Analog DID for Cisco 2600 and Cisco 3600 Series Routers를 참조하십시오.

참고: 대부분의 플랫폼에서 DID는 CAS(immediate, wink, delay) 인터페이스에서 기본적으로 활성화되어 있습니다. 따라서 수신 통화에 대해 direct-inward-dial 명령을 구성하지 마십시오. Cisco AS5300 플랫폼에서는 E & M Immediate Signaling용으로 구성된 인터페이스에서 DID가 지원되지 않습니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다. 이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

배경 정보

DID는 전화회사에서 제공하는 서비스로, 발신자가 교환원이나 자동 통화 교환원의 지원 없이 PBX(Private Branch eXchange) 또는 패킷 음성 시스템의 내선 번호로 직접 전화를 걸 수 있습니다. 이 서비스에서는 DID 트렁크를 사용하여 전화 번호의 마지막 3~5자리 숫자만 PBX 또는 라우터/게이트웨이로 전달합니다. 예를 들어, 회사에 전화 내선 번호가 555-1000~555-1999이고 발신자 번호가 555-1234인 경우, CO(Local Central Office)는 234를 PBX 또는 패킷 음성 시스템으로 전달합니다. 그러면 PBX 또는 패킷 음성 시스템(Cisco CallManager 및 IOS 라우터/게이트웨이)이 내선 번호 234로 연결됩니다. 이 전체 프로세스는 발신자에게 투명합니다.

이 문서에서는 다음과 같이 두 가지 유형의 다이얼 피어에 대해 설명합니다.

• POTS(Plain old telephone service)—PSTN(Public Switched Telephone Network)을 통해 수행되는 기존 음성 통화입니다. 이 경우 통화 중에 전용 64K 회선 엔드 투 엔드 통화 레그가 제공됩니다. POTS 다이얼 피어는 항상 라우터의 음성 포트를 가리킵니다.

• Voice-Network(음성 네트워크) - 데이터 네트워크를 통한 음성 통화는 여러 통화 레그로 구성됩니다. 각 통화 레그는 데이터 장치(라우터/게이트웨이) 간에 또는 데이터 장치와 텔레포니 장치(예: 라우터에서 PBX로) 간에 이동합니다. 음성-네트워크 다이얼 피어가 사용하는 네트워크 기술에 따라 다른 대상을 가리킵니다. 음성 네트워크 다이얼 피어는 다음과 같습니다.

  • VoIP(Voice over IP)

  • VoFR(Voice over Frame Relay)

  • VoATM(Voice over ATM)

  • MMoIP(Multimedia Mail over IP)

Cisco IOS 라우터/게이트웨이로 음성 전화가 오면 라우터의 음성 포트가 PBX 또는 CO 스위치에 의해 인바운드로 잡힙니다. 그런 다음 라우터/게이트웨이가 발신자에게 발신음을 표시하고 아웃바운드 다이얼 피어를 식별할 수 있을 때까지 숫자를 수집합니다. 사람이 불규칙한 간격으로 번호를 다이얼하든, 텔레포니 장비가 미리 수집된 번호를 전송하든, 다이얼 피어 매칭을 한 자릿수로 수행합니다. 이는 라우터/게이트웨이가 각 숫자를 수신한 후 다이얼 피어와 매칭을 시도함을 의미합니다. 이 프로세스를 2단계 다이얼링이라고 합니다.

그러나 PBX 또는 CO 스위치에서 통화를 완전히 라우팅하는 데 필요한 숫자가 "모두"로 포함된 설정 메시지를 보내는 경우, 이러한 숫자는 아웃바운드 음성 네트워크 다이얼 피어에 직접 매핑될 수 있습니다. DID를 사용하면 라우터/게이트웨이가 발신자에게 신호음을 표시하지 않으며 숫자를 수집하지 않습니다. 구성된 대상으로 통화를 직접 전달합니다. 이를 1단계 다이얼링이라고 합니다.

위의 단락에서 설명한 통화를 라우팅하는 데 필요한 숫자는 다음 두 가지 유형으로 구성됩니다.

• DNIS(Digital Number Identification Service)는 텔코에서 제공하는 디지털 서비스로서, 호출된 번호(전화를 건 번호)를 제공합니다.

• ANI(Automatic Number Identification)는 텔코에서 제공하는 디지털 서비스로 발신 번호(통화 발신자의 번호)를 제공합니다. ANI는 CLID(Calling Line Identification)라고도 합니다.

POTS 다이얼 피어에 대한 DID 컨피그레이션

POTS(Plain Old Telephone Service) 인터페이스에서 인바운드 전화를 받을 때 다이얼 피어의 DID 기능을 사용하면 라우터/게이트웨이가 DNIS(Called Number)를 사용하여 아웃바운드 다이얼 피어와 직접 매칭할 수 있습니다. 인바운드 POTS 다이얼 피어에서 DID가 구성된 경우 아웃바운드 통화 레그의 대상 패턴과 일치하는 수신 번호가 자동으로 사용됩니다.

DID에 대해 POTS 다이얼 피어를 구성하려면 글로벌 컨피그레이션 모드에서 시작하는 다음 Cisco IOS 명령을 입력합니다.

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

DID에 대한 올바른 인바운드 POTS 다이얼 피어 매칭

DID가 올바르게 작동하려면 수신 통화가 직접 내부 다이얼 명령이 구성된 올바른 POTS 다이얼 피어와 일치하는지 확인합니다. 올바른 인바운드 다이얼 피어를 매칭하려면 DID POTS 다이얼 피어 아래에서 dial peer 명령 incoming called-number dnis_string을 사용하는 것이 좋습니다.

다이얼 피어를 확인하는 데 사용되는 기타 명령으로는 ani_string answer-address , destination-pattern string 또는 port voice-port 가 있습니다. incoming called-number 명령을 사용하면 모든 통화에 연결된 DNIS 정보(called-number)가 있으며 이전 명령보다 우선 순위가 높다는 장점이 있습니다.

incoming called-number 명령을 사용하여 인바운드 다이얼 피어를 매칭하지 않을 경우 다음을 고려하십시오.

• ANI 정보를 사용하여 DID POTS 다이얼 피어와 일치시키는 경우 answer-address 명령이 올바르게 구성되어 있고 telco-switch가 ANI 정보를 제공하고 있는지 확인합니다. fgd(Feature Group D)를 제외한 일부 ISDN 제공자 및 대부분의 T1 CAS(channel associated signaling)는 ANI 정보를 제공하지 않습니다.

• answer-address가 ANI와 일치하지 않으면 ANI가 다른 POTS 다이얼 피어에 구성된(아웃바운드 다이얼링을 위해) 대상 패턴과 일치할 수 있습니다. destination-pattern이 ANI와 일치하는 경우 direct-inward-dial 명령이 해당 다이얼 피어에서 구성되었는지 확인합니다.

• 수신 DID 통화가 수신 수신 전화 번호 또는 응답 주소 또는 대상 패턴 또는 포트를 기반으로 하는 인바운드 POTS 전화 피어와 일치하지 않을 경우, 기본 전화 걸기 피어 0이 사용됩니다. DID는 다이얼 피어 0에서 기본적으로 비활성화되어 있습니다.

사례 연구

다음 예를 사용하여 위 사항을 설명하십시오. ACME Company는 555-3100~555-3139 범위의 DID 트렁크가 40개인 T1 PRI 라인을 보유하고 있습니다. 목표는 처음 20개 회선을 Cisco IP Phone에 할당하는 것입니다. 마지막 20개 회선은 테스트, 향후 확장 등에 사용할 수 있으며, 현재로서는 라우터가 신호음만 제공합니다. CO 스위치가 ISDN 설정 메시지의 마지막 다섯 자리만 전송한다고 가정하면, 위의 정보를 다음 표에 요약할 수 있다.

PSTN 사용자 다이얼	스위치에서 음성 라우터/게이트웨이로 보낸 숫자	Use	트렁크 수
555-3100 ~ 555-3119	53100 - 53119	IP 전화에 대한 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의 출력에서 형식이 다릅니다.

• 디버그 voip ccapi 인아웃에서 Q.931 통화 연결 끊김 원인 코드를 해석하려면 다음을 참조하십시오. 문제 해결 및 디버그 VoIP 통화 - 기본

• debug isdn q931에서 Q.931 통화 연결 끊김 원인 코드를 해석하려면 debug isdn q931 연결 끊김 원인 코드 이해를 참조하십시오.

Q.931 이벤트 원인 코드를 10진수 형식으로 보려면 다음을 참조하십시오. ISDN 이벤트 원인 코드

다음은 증상의 몇 가지 예제와 증상을 일으킬 수 있는 문제입니다.

• 증상: 라우터/게이트웨이는 발신음을 제공하며, 인터숫자 타이머가 시간 초과될 때까지 기다립니다. 그런 다음 debug voip ccapi inout 원인 코드 = 0x1C(잘못된 숫자 형식) 또는 debug isdn q931(ISDN 인터페이스의 경우) 연결 끊기 원인 코드 = 0x809C(잘못된 숫자 형식)로 연결을 끊습니다.

  • 문제: DID가 Cisco IOS 라우터/게이트웨이가 아닌 Telco 스위치에서 구성되었습니다.

• 증상: 라우터/게이트웨이가 디버그 voip ccapi 입력 원인 코드 = 0x1(할당되지 않은/할당되지 않은 번호) 또는 디버그 isdn q931(ISDN 인터페이스의 경우) 연결 끊기 원인 코드 = 0x8081(할당되지 않은/할당되지 않은 번호)과 연결이 끊어집니다.

  • 문제: DID가 구성되어 있고 올바른 인바운드 POTS 다이얼 피어가 Cisco IOS 라우터/게이트웨이에서 일치하지만 설정 메시지에 DNIS(Called-Number)가 포함되어 있지 않습니다. 이 경우 텔코에서 트렁크가 DID에 대해 프로비저닝되었는지 확인합니다.

• 증상: 라우터/게이트웨이가 디버그 voip ccapi 원인 코드 = 0x1(할당되지 않은/할당되지 않은 번호) 또는 디버그 isdn q931(ISDN 인터페이스의 경우) 연결 끊기 원인 코드 = 0x8081(할당되지 않은/할당되지 않은 번호)과 연결이 끊어집니다.

  • 문제: DID가 구성되어 Cisco IOS 라우터/게이트웨이에서 확인되지만 라우터/게이트웨이에서 아웃바운드 다이얼 피어가 일치하지 않습니다.

  • 문제: 수신 전화가 direct-inward-dial 명령이 구성된 올바른 POTS 다이얼 피어와 일치하는지 확인합니다. 자세한 내용은 이 문서의 DID에 대한 올바른 인바운드 POTS 다이얼 피어 일치 섹션을 참조하십시오

샘플 표시 및 디버그 출력

참고: 다음 디버그 출력 라인 중 일부는 인쇄를 위해 여러 라인으로 나뉩니다.

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