IOS Voice Digital(T1/E1) 인터페이스에서 DID(Direct-Inward-Dial) 이해
목차
소개
이 기술 메모는 디지털 인터페이스가 있는 Cisco IOS 음성 지원 라우터/게이트웨이(T1/E1)에 적용됩니다. Cisco Analog Direct Inward Dialing(DID)에 대한 자세한 내용은 다음을 참조하십시오.Cisco 2600 및 Cisco 3600 Series 라우터용 아날로그 DID
참고: 대부분의 플랫폼에서 DID는 CAS(Immediate, Unk, Delay) 인터페이스에서 기본적으로 활성화됩니다.따라서 수신 통화에 대해 다이렉트-안쪽으로 다이얼 명령을 구성하지 마십시오.Cisco AS5300 플랫폼에서는 E & M 즉각적인 신호 처리를 위해 구성된 인터페이스에서 DID가 지원되지 않습니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
배경 정보
DID는 전화 회사가 제공하는 서비스로서 발신자가 교환이나 자동 통화 교환 없이 PBX(Private Branch Exchange) 또는 패킷 음성 시스템의 내선으로 직접 전화를 걸 수 있습니다.이 서비스는 전화 번호의 마지막 3~5자리만 PBX 또는 라우터/게이트웨이로 전달하는 DID 트렁크를 사용합니다.예를 들어, 한 회사가 전화 내선 번호 555-1000~555-1999를 가지고 있고 발신자가 555-1234로 전화를 걸면, 로컬 중앙 사무실(CO)은 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)
-
MooIP(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) 인터페이스에서 인바운드 통화를 수신할 때 다이얼 피어의 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 명령을 사용하는 것이 좋습니다.
다이얼 피어와 일치시키는 데 사용되는 기타 명령은 다음과 같습니다.answer-address ani_string, destination-pattern 문자열 또는 port voice-port.incoming called-number 명령을 사용하면 모든 통화에 연결된 DNIS 정보(called-number)가 있으며 이전 명령보다 우선순위가 높습니다.
인바운드 다이얼 피어와 일치시키기 위해 incoming called-number 명령을 사용하지 않는 경우 다음을 고려하십시오.
-
ANI 정보를 사용하여 DID POTS 다이얼 피어와 일치시키는 경우 명령 응답 주소가 올바르게 구성되고 telco-switch가 ANI 정보를 제공하는지 확인합니다.일부 ISDN 제공자 및 fgd(Feature Group D)를 제외한 대부분의 T1 채널 관련 신호(CAS)는 ANI 정보를 제공하지 않습니다.
-
ANI에 대한 응답 주소가 일치하지 않으면 ANI가 다른 POTS 다이얼 피어 아래에 구성된 대상 패턴(아웃바운드 다이얼용)과 일치할 수 있습니다.대상 패턴이 ANI와 일치하는 경우 해당 다이얼피어 아래에 직접 안쪽으로 다이얼이 구성되어 있는지 확인합니다.
-
수신 DID 통화가 수신 전화 번호 또는 응답 주소 또는 대상 패턴 또는 포트를 기준으로 인바운드 POTS 다이얼 피어와 일치하지 않으면 기본 다이얼 피어 0이 사용됩니다.DID는 다이얼 피어 0에서 기본적으로 비활성화되어 있습니다.
사례 연구
다음 예를 사용하여 위의 점을 설명합니다.ACME Company에는 555-3100~555-3139 범위의 40개의 DID 트렁크가 있는 T1 PRI 라인이 있습니다.첫 20개의 회선을 Cisco IP 전화에 할당하는 것이 목표입니다.마지막 20개의 회선은 테스트, 향후 확장을 위해 사용할 수 있으며 지금은 라우터가 신호음만 제공합니다.CO 스위치가 ISDN 설정 메시지의 마지막 5자리만 전송한다고 가정할 때 다음 표에 위 정보를 요약할 수 있습니다.
| 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 출력에서 다른 형식을 갖습니다.
-
Q.931 통화 연결 해제 원인 코드를 debug voip capi inout에서 해석하려면 다음을 참조하십시오.문제 해결 및 VoIP 통화 디버그 - 기본 사항
-
디버그 isdn q931의 Q.931 통화 연결 해제 원인 코드를 해석하려면 다음을 참조하십시오.디버그 isdn q931 연결 해제 원인 코드 이해
10진수 형식의 Q.931 이벤트 원인 코드를 보려면 다음을 참조하십시오.ISDN 이벤트 원인 코드 
다음은 증상을 일으키는 몇 가지 증상과 문제의 예입니다.
-
증상:라우터/게이트웨이는 다이얼톤을 제공하고 인터숫자 타이머가 시간 초과될 때까지 기다립니다.그런 다음 debug voip capi inout 원인 코드 = 0x1C(잘못된 번호 형식) 또는 debug isdn q931(ISDN 인터페이스용) 연결 해제 원인 코드 = 0x809C(잘못된 번호 형식)와 연결이 끊깁니다.
-
문제:DID는 Telco 스위치에 구성되었지만 Cisco IOS 라우터/게이트웨이에는 구성되지 않았습니다.
-
-
증상:라우터/게이트웨이가 디버그 voip capi 인아웃 원인 코드 = 0x1(할당되지 않은/할당되지 않은 번호) 또는 debug isdn q931(ISDN 인터페이스용) 연결 해제 원인 코드 = 0x8081(할당되지 않은/할당되지 않은 번호)와 연결을 끊습니다.
-
문제:DID가 구성되고 Cisco IOS 라우터/게이트웨이에서 올바른 인바운드 POTS 다이얼 피어가 일치하지만 설정 메시지에 DNIS(called-number)가 포함되지 않습니다. 이 경우 텔코와 함께 트렁크가 DID에 대해 프로비저닝되었는지 확인합니다.
-
-
증상:라우터/게이트웨이가 디버그 voip ccapi inout 원인 코드 = 0x1(할당되지 않은/할당되지 않은 번호) 또는 debug isdn q931(ISDN 인터페이스용) 연결 해제 원인 코드 = 0x8081(할당되지 않은/할당되지 않은 번호)와 연결을 끊습니다.
-
문제:DID가 Cisco IOS 라우터/게이트웨이에서 구성 및 일치하지만 라우터/게이트웨이에 아웃바운드 다이얼 피어가 일치하지 않습니다.
-
문제:수신 통화가 명령 다이렉트-안쪽으로 다이얼이 구성된 올바른 POTS 다이얼 피어와 일치하는지 확인합니다.자세한 내용은 이 문서의 Matching the Correct Inbound POTS Dial Peer for DID 섹션을 참조하십시오.
-
샘플 표시 및 디버그 출력
참고: 다음 디버그 출력 줄 중 일부는 인쇄 목적으로 여러 행으로 구분됩니다.
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
피드백