목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

표기 규칙

문제 해결 사전 요구 사항: ISDN Layer 3 디버깅 활성화

ISDN 통화 시작

문제 해결 개요: 증상 및 해결 절차

문제 해결: 증상 및 세부 해결 절차

발신 라우터가 SETUP 메시지를 보내지 않습니다.

Called Router가 SETUP 메시지를 수신하지 않습니다.

호출된 라우터가 CONNECT 메시지를 보내지 않습니다.

발신 라우터가 CONNECT 메시지를 수신하지 않습니다.

발신 라우터가 CONNECT를 수신하지만 통화는 여전히 실패합니다.

관련 정보

소개

ISDN 통화 실패 문제를 해결할 때 다음 중 하나로 인해 통화가 실패할 수 있다는 점에 유의해야 합니다.

- DDR(Dial-on-Demand Routing)

- ISDN 레이어 1, 2 및 3

- PPP(Point-to-Point Protocol): LCP(Link Control Protocol), 인증 또는 IPCP(IP Control Protocol) 관련 문제 포함

이 문서에서는 통화 장애를 일으키는 ISDN 관련 문제에 대해 특히 중점적으로 다룹니다. 이 문서에서는 회로의 양쪽 끝에 있는 ISDN Layers 1 및 2가 작동하는지 확인했다고 가정합니다. ISDN Layer 1 및 2 상태 확인에 대한 자세한 내용은 BRI 문제 해결을 위해 show isdn status 명령 사용을 참조하십시오.

사전 요구 사항

요구 사항

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

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.

표기 규칙

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

문제 해결 사전 요구 사항: ISDN Layer 3 디버깅 활성화

양쪽 끝에 debug isdn q931 명령을 사용하여 ISDN Layer 3 디버그를 활성화합니다. 두 라우터에서 모두 활성화된 디버그의 타임스탬프도 밀리초 미만이어야 합니다. 타임스탬프는 문제 해결 프로세스에 대한 상대적 입력을 제공하기 위해 필요합니다.

참고: 다음 명령을 사용하여 디버그에 대한 밀리초 타임스탬프를 활성화합니다.

maui-soho-01(config)#service timestamps debug datetime msec

maui-soho-01(config)#service timestamps log datetime msec

debug 명령에 대한 자세한 내용은 Debug 명령에 대한 중요 정보를 참조하십시오.

ISDN 통화 시작

원격 라우터 IP 주소에 대한 ICMP ping을 생성합니다. 이렇게 하면 해당 라우터에 대한 ISDN 통화가 시작됩니다. 두 라우터 모두 디버그 isdn q931 메시지를 생성합니다.

Q.931 교환에는 ISDN 스위치 유형에 대한 특정 요구 사항 또는 추가 매개 변수가 필요한 경우 다양한 변형이 있을 수 있습니다. 다음 다이어그램은 성공적인 ISDN 통화 설정 중 일반적인 Q.931 트랜잭션을 보여줍니다.

참고: 다음 디버그 출력 줄 중 일부는 인쇄 목적으로 여러 행으로 구분됩니다.

발신 라우터

호출된 라우터

maui-soho-01#

18:39:29.425: ISDN BR0: TX -> SETUP

pd = 8  callref = 0x10

!-- The Calling Router Transmits !-- (indicated by TX) the SETUP message

18:39:29.433:

Bearer Capability i = 0x8890

18:39:29.441: Channel ID i = 0x83

18:39:29.449:

Keypad Facility i = '5558888'

18:39:29.822: ISDN BR0: RX <- CALL_PROC

pd = 8  callref = 0x90

!-- The telco switch responds with a !-- Call Proceeding. This indicates the !-- network is processing the call.

18:39:29.830:

Channel ID i = 0x89

.

.

.

!-- Nothing has been omitted here. The !-- dots were put in place to align !-- the Called and Calling Routers.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18:39:30.000: ISDN BR0: RX <- CONNECT

pd = 8  callref = 0x90

!-- Received a CONNECT from the remote !-- router. The ISDN connection has been !-- established. Any failures of the call !-- past this point are due to higher !-- level issues such as DDR, PPP, !-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK

pd = 8  callref = 0x10

!--- The Router responds with a Connect !--- Acknowledgment (CONNECT_ACK) !--- to the telco.

maui-nas-08#

18:39:29.647: ISDN BR2/0: RX <- SETUP

pd = 8  callref = 0x08

!-- The Called Router receives !-- (indicated by RX) a SETUP message !-- from the switch

18:39:29.647:

Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital.

18:39:29.647: Channel ID i = 0x89

18:39:29.647:

Signal i = 0x40 - Alerting on -

pattern 0

18:39:29.647:

Called Party Number i = 0xC1,'5558888',

Plan:ISDN, Type:Subscriber(local)

18:39:29.647:

Locking Shift to Codeset 5

18:39:29.647:

Codeset 5 IE 0x2A

i = 0x808001038001118001, '<'

18:39:29.651:

ISDN BR2/0: Event: Received a DATA

call from  on B1 at 64 Kb/s

18:39:29.651: ISDN BR2/0: TX -> CALL_PROC

pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding

18:39:29.655:

Channel ID i = 0x89

18:39:29.655: %LINK-3-UPDOWN:

Interface BRI2/0:1, changed state to up

18:39:29.955: ISDN BR2/0: TX -> CONNECT

pd = 8  callref = 0x88

!--- Call is accepted and the routers sends !--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89

18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK

pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK !--- from the switch

18:39:29.995:

Channel ID i = 0x89

18:39:29.995:

Signal i = 0x4F - Alerting off

18:39:35.655: %ISDN-6-CONNECT:

Interface BRI2/0:1 is now

connected to unknown

호출과 호출된 끝에 대한 디버그 isdn q931 출력을 평가할 때 다음 사항에 유의하십시오.

- 메시지의 방향에 주의하십시오. 디버그는 라우터에서 메시지를 생성했는지(TX ->로 표시됨) 또는 라우터에서 메시지를 수신했는지(RX <—)를 나타냅니다. 아래 예에서는 라우터에서 ISDN 스위치로부터 첫 번째 메시지(CONNECT)를 수신하고 두 번째 메시지(CONNECT_ACK)는 라우터에서 전송합니다.

18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90

18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10

특정 메시지의 방향과 응답에 따라 문제의 원인을 식별할 수 있습니다. 예를 들어, 라우터가 예기치 않게 텔코 ISDN 스위치에서 RELEASE 메시지를 수신하면 연결 끝도 재설정됩니다. 이는 문제가 텔코 ISDN 스위치 또는 원격 라우터에 있음을 나타냅니다.

- 수신 또는 전송된 메시지가 필요한 메시지인지 확인합니다. 예를 들어, 수신자가 SETUP 메시지를 수신하지만 CONNECT 대신 DISCONNECT를 전송하면 ISDN 네트워크가 아닌 호출된 라우터의 문제를 해결합니다. 다음 표에는 통화 설정 및 해제 중에 표시될 수 있는 Q.931 메시지 목록이 나와 있습니다.

메시지

설명

설정

설정 — 디바이스가 레이어 3 통화를 설정하려고 함을 나타냅니다.

통화_프로세스

통화 진행 — 통화 SETUP을 수신하여 네트워크 및/또는 원격 장치에서 처리 중입니다.

경고

경고 — 최종 라우터가 이제 사용자에게 '알림'을 하고 있음을 네트워크에 알립니다. 이는 보통 전화기의 경우이며 경고문은 핸드셋의 "링"이 될 것이다. 이 메시지는 일반적으로 ISDN 전화 또는 TA와 같은 핸드셋을 사용하는 장비와 연결되며 일반적으로 데이터 통화에는 나타나지 않습니다.

연결

연결 - 통화가 수락됨

연결_ACK

Connect Acknowledge(연결 승인) - 디바이스가 CONNECT 메시지를 수신했습니다. 상위 레이어 프로토콜(예: PPP)는 이제 협상을 시작해야 합니다.

연결 끊기

연결 끊기 — 라우터가 연결 끊기 메시지를 시작했습니다. 이 메시지는 일반적으로 ISDN 회로가 작동하고 있으며 연결이 일부 더 높은 계층 문제(DDR, PPP 등)의 결과임을 나타냅니다. 3방향 연결 끊기 핸드셰이크는 RELEASE 및 RELEASE_COMP 메시지와 함께 제공됩니다. DISCONNECT 메시지에는 연결 끊기 원인 코드도 함께 표시됩니다. 이 연결 끊기 코드를 사용하여 통화가 연결이 끊어진 위치를 정확하게 찾아낼 수 있습니다(예: 통화가 라우터, 로컬 통신 스위치, 원격 통신 스위치 등에서 연결이 끊겼음). 자세한 내용은 디버그 isdn q931 연결 해제 원인 코드 이해를 참조하십시오.

릴리스

릴리스 — DISCONNECT를 승인하고 회선 해체 작업을 계속합니다. RELEASE 메시지는 DISCONNECT와 RELEASE_COMP 메시지 사이에 배치됩니다. RELEASE 메시지에는 연결 끊기 원인 코드와 함께 사용할 수 있습니다. 이 연결 끊기 코드를 사용하여 통화가 연결이 끊어진 위치를 찾아낼 수도 있습니다(예: 통화가 라우터, 로컬 텔코 스위치, 원격 텔코 스위치에서 연결이 끊어진 경우). 자세한 내용은 디버그 isdn q931 연결 해제 원인 코드 이해를 참조하십시오.

RELEASE_COMP

릴리스 완료 — 통화 해체 완료 이 메시지는 일반적으로 다음과 같습니다. a) 라우터 중 하나에서 시작한 정상적인 통화 종료 중 b) 발신 라우터의 설정 메시지에 대한 응답으로. 이는 스위치와 라우터 간의 베어러 기능 불일치로 인해 발생하는 경우가 많습니다. SETUP 메시지의 코딩이 Q.931 표준을 준수하지 않거나 스위치의 컨피그레이션을 준수하지 않는 경우 RELEASE_COMP는 연결 끊기 원인 코드와 함께 발생할 수 있습니다. 이 연결 끊기 코드를 사용하여 통화가 연결이 끊어진 위치를 찾아낼 수도 있습니다(예: 통화가 라우터, 로컬 텔코 스위치, 원격 텔코 스위치에서 연결이 끊어진 경우). 자세한 내용은 디버그 isdn q931 연결 끊김 원인 코드 이해를 참조하십시오.

문제 해결 개요: 증상 및 해결 절차

이전 섹션에 설명된 대로 debug isdn q931 출력을 분석하고 아래 설명된 적절한 증상을 진행합니다.

참고: 이 문서에서는 통화를 시작하는 라우터를 통화 라우터라고 하며, 통화를 수락하는 라우터를 수신자 라우터라고 합니다.

문제 해결: 증상 및 세부 해결 절차

발신 라우터가 SETUP 메시지를 보내지 않습니다.

통화 라우터가 ISDN 네트워크로 SETUP 메시지를 보내지 않을 경우, 이 문제는 ISDN 레이어 1, 2 또는 DDR(Dial-on-Demand Routing) 문제와 관련이 있을 수 있으며 레이어 3 관련 문제가 아닙니다.

발신 라우터에서 다음 작업을 수행합니다.

- ISDN 스위치 유형이 올바르게 구성되었는지 확인합니다.

ISDN 스위치 유형은 show isdn status 명령을 사용하여 확인할 수 있습니다. 텔코는 구성해야 하는 스위치 유형을 명시적으로 표시해야 합니다. 때때로(특히 북미 지역의 경우) 텔레코에서 스위치 유형이 "맞춤형" 또는 "국내"임을 나타낼 수 있습니다. 이러한 경우 다음 지침을 사용하여 스위치 유형 컨피그레이션을 결정합니다.

- 사용자 지정: telco가 스위치 유형이 Custom임을 나타내는 경우, 라우터의 스위치 유형을 basic-5ess(5ess 스위치가 있는 BRI), primary-5ess(5ess가 있는 PRI의 경우), basic-dms(DMS 스위치가 있는 BRI의 경우) 또는 primary-dms(DMS가 있는 PRI의 경우)로 구성합니다.

- 전국: BRI의 NI-1 표준과 PRI의 NI-2 표준을 따르는 스위치 유형(PRI의 NI-1 표준은 없음) switchtype이 National임을 텔코에서 알리면 Cisco 라우터 컨피그레이션은 basic-ni(BRI의 경우) 또는 primary-ni(PRI의 경우)여야 합니다.

switchtype을 구성하려면 BRI 인터페이스 컨피그레이션 모드에서 isdn switch-type switch-type 명령을 사용합니다. 예제는 ISDN BRI Layer 1 문제 해결을 참조하십시오.

- 호출 라우터의 ISDN Layers 1 및 2가 작동하는지 확인합니다.

show isdn status 명령을 사용하여 ISDN Layers 1 및 2가 작동 중인지 확인할 수 있습니다. ISDN Layer 1 및 2 관련 문제를 해결하려면 에 설명된 절차를 사용하십시오.

- show ip route 명령을 사용하여 라우터가 대상에 대한 경로를 가지고 있는지 확인합니다.

show ip route 명령은 원격 라우터 네트워크에 대한 경로가 있는지 여부를 나타냅니다. 경로가 존재하지 않으면 ip route 명령을 사용하여 원격 네트워크에 대한 고정 경로를 추가합니다. 경로가 발신 라우터의 올바른 인터페이스를 가리키는지 확인합니다.

레거시 DDR 환경(예: 다이얼러 맵)에서 다음 홉은 물리적 인터페이스 네트워크(인터페이스 BRI x) 또는 원격 라우터 IP 주소(다이얼러 맵 명령문에도 구성되어야 함)여야 합니다.

다이얼러 프로파일의 경우 다음 홉은 일반적으로 다이얼아웃에 사용되는 인터페이스 다이얼러 x입니다. 예를 들어

maui-soho-01#show ip route

...

...

!-- Output omitted

...

10.0.0.0/24 is subnetted, 1 subnets

C       10.0.0.0 is directly connected, Ethernet0

S*   0.0.0.0/0 is directly connected, Dialer1

위의 예에서 기본 경로 next hop은 interface Dialer 1(이 연결의 논리적 다이얼러 인터페이스)입니다.

- 흥미로운 트래픽이 올바르게 식별되었는지 확인합니다.

라우터는 다이얼을 시작하기 전에 수신 패킷이 흥미로운 트래픽인지 확인합니다. 따라서 흥미로운 트래픽이 잘못 정의되거나 다이얼러 목록 번호(흥미로운 트래픽 정의)가 물리적 또는 다이얼러 인터페이스(dialer-group number 명령 사용)에 적용되지 않으면 라우터가 다이얼하지 않을 수 있습니다. 예를 들어 ICMP ping을 사용하여 DDR 연결을 시작하는 경우 ICMP가 흥미로운 트래픽 정의에서 허용되는지 확인합니다.

자세한 내용은 DDR 다이얼러 맵을 사용하여 BRI-BRI 다이얼업 구성을 참조하십시오.

- 적절한 다이얼러 문자열(또는 다이얼러 맵)에 원격 디바이스의 ISDN 번호가 포함되어 있는지 확인합니다.

다이얼러 문자열(또는 다이얼러 맵)에는 원격 라우터의 ISDN 번호가 포함되어야 합니다. 예를 들어

dialer string 5551111

or

dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111

- DDR 구성을 확인하고 디버그 다이얼러를 사용하여 라우터가 통화를 시작하는지 확인합니다.

DDR 구성이 올바른지 확인합니다. 문서 전화 접속 기술 사용: 올바른 DDR 구성에 대한 추가 지원을 위한 개요 및 설명

또한 디버그 다이얼러 명령을 사용하여 라우터가 관심 있는 트래픽을 수신하고 다이얼러 맵 또는 다이얼러 문자열을 사용하여 다이얼을 시작하는지 확인해야 합니다. 위의 문서와 전화 접속 기술을 참조하십시오. 자세한 내용은 문제 해결 기술을 참조하십시오.

적절한 DDR 컨피그레이션의 예는 다음 샘플 컨피그레이션을 참조하십시오.

다이얼러 프로파일: 다이얼러 프로파일을 사용하여 ISDN DDR 구성 레거시 DDR(다이얼러 맵): DDR 다이얼러 맵을 사용하여 BRI-BRI 다이얼업 구성

팁: 테스트 목적으로 다음 섹션에서 설명한 isdn call 명령을 사용하여 원격 디바이스에 대한 ISDN 호출을 생성하여 DDR을 제거할 수 있습니다. 해당 통화가 성공하면 ISDN 회로가 제대로 작동하는지 합리적으로 확인할 수 있습니다. DDR 문제 해결을 계속합니다.

- 루프백 테스트 호출 수행

루프백 호출에서 라우터는 자체 BRI의 ISDN 번호로 전화를 겁니다. 통화가 텔코 클라우드로 진행되며, 여기서 telco는 통화를 두 번째 BRI 채널로 전환합니다. 이제 라우터에서 이 통화를 두 번째 채널의 수신 통화로 볼 수 있습니다. 따라서 라우터는 ISDN 통화를 보내고 받습니다.

루프백 통화는 라우터가 ISDN 통화를 시작하고 종료하는 기능을 테스트합니다. 루프백 호출이 성공하면 텔코 클라우드에 대한 ISDN 회로가 올바르게 작동함을 확실하게 알 수 있습니다.

다음은 성공적인 루프백 호출의 주석 처리된 예입니다. isdn 호출(Cisco IOS® 소프트웨어 12.0(3)T에 도입됨) 명령은 흥미로운 트래픽 및 경로와 같은 DDR 요구 사항이 없어도 발신 isdn 호출을 활성화합니다. 이 명령은 ISDN 회로의 테스트에만 사용할 수 있으며 트래픽을 전달하거나 적절한 DDR 구성을 대체하는 데 사용할 수 없습니다. 이 명령을 사용하면 ISDN 회로(특히 레이어 3)가 작동하는지 확인할 수 있습니다.

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#

*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890

*Mar  1 17:55:08.360:         Channel ID i = 0x83

*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'

*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89

*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890

*Mar  1 17:55:08.520:         Channel ID i = 0x8A

*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0

*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'

*Mar  1 17:55:08.532:         Locking Shift to Codeset 5

*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'

*Mar  1 17:55:08.564: ISDN BR0: Event:

Received a DATA call from  on B2 at 64 Kb/s

*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1

*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A

*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up

*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A

*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A

*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off

*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09

*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0

*Mar  1 17:55:09.112: %ISDN-6-CONNECT:

Interface BRI0:1 is now connected to 5551111

! --- Call is now connected. Loopback call is successful

참고:

- 루프백 통화 중에 라우터는 발신된 라우터와 호출 라우터(다른 B 채널에서는)의 역할을 수행합니다. debug isdn q931 출력을 해석할 때 이러한 "이중 역할"을 계속 추적하는 것이 중요합니다. 예를 들어, 라우터는 설정 메시지(TX -> SETUP)를 전송하고 하나를 수신합니다(RX <- SETUP). 수신된 SETUP 메시지가 수신 통화에 연결된 동안 전송된 SETUP을 발신 통화에 연결해야 합니다.

- 위 예에서는 첫 번째 B-채널의 번호로 전화를 걸었습니다. 그러나 첫 번째 B-채널이 통화 중임을 인식한 통신사는 통화를 두 번째 B-채널로 전환한 후 연결이 성공적으로 완료되었습니다. 그러나 telco 스위치의 컨피그레이션이 잘못되면 스위치에서 첫 번째 채널에 통화를 할당하려고 시도하기 때문에(통화 중) 루프백 호출이 실패할 수 있습니다. 통신사가 이 문제를 해결해야 한다. 그러나 해결 방법으로 isdn 호출에 두 번째 B-channel 번호를 지정합니다.

- 루프백 호출이 성공하고 원격 엔드로의 통화가 계속 실패할 경우, BRI 회로에 대한 추가 문제 해결 지원을 받으려면 통신사에 문의하십시오.

Called Router가 SETUP 메시지를 수신하지 않습니다.

통화 라우터가 ISDN Layer 3 SETUP 메시지를 전송하지만 Called Router가 메시지를 수신하지 않는다고 판단하면 문제가 Called Router의 ISDN Layers 1 및 2에 있거나 Telco ISDN 클라우드에 문제가 있을 수 있습니다.

호출된 라우터에서 다음 작업을 수행합니다.

- ISDN 스위치 유형이 올바르게 구성되었는지 확인합니다.

ISDN 스위치 유형은 show isdn status 명령을 사용하여 확인할 수 있습니다. 텔코는 구성해야 하는 스위치 유형을 명시적으로 표시해야 합니다. 때때로(특히 북미 지역의 경우) 텔레코에서 스위치 유형이 "맞춤형" 또는 "국내"임을 나타낼 수 있습니다. 이러한 경우 다음 지침을 사용하여 스위치 유형 컨피그레이션을 결정합니다.

- 사용자 지정: telco가 스위치 유형이 Custom임을 나타내는 경우, 라우터의 스위치 유형을 basic-5ess(5ess 스위치가 있는 BRI), primary-5ess(5ess가 있는 PRI), basic-dms(DMS 스위치가 있는 BRI의 경우) 또는 primary-dms(DMS가 있는 PRI의 경우)로 구성합니다.

- 전국: BRI의 NI-1 표준과 PRI의 NI-2 표준을 따르는 스위치 유형(PRI의 NI-1 표준은 없음) switchtype이 National임을 텔코에서 알리면 Cisco 라우터 컨피그레이션은 basic-ni(BRI의 경우) 또는 primary-ni(PRI의 경우)여야 합니다.

switchtype을 구성하려면 BRI 인터페이스 컨피그레이션 모드에서 isdn switch-type 스위치 유형을 사용합니다. 예제는 ISDN BRI Layer 1 문제 해결을 참조하십시오.

- 호출 라우터의 ISDN Layers 1 및 2가 작동하는지 확인합니다.

show isdn status 명령을 사용하여 ISDN Layers 1 및 2가 작동 중인지 확인할 수 있습니다. ISDN Layer 1 및 2 관련 문제를 트러블슈팅하려면 BRI 문제 해결을 위해 show isdn status 명령 사용에 설명된 절차를 사용합니다.

- SPID LDN(Local Directory Number)이 올바르게 구성되었는지 확인합니다.

특정 스위치 유형에서는 수신 통화를 수락하려면 spid 및 ldn이 올바르게 구성되어 있어야 합니다. 자세한 내용은 ISDN BRI SPID 문제 해결을 참조하십시오.

발신 라우터에서 다음 작업을 수행합니다.

- 일반 아날로그 전화기를 사용하여 원격 라우터에 대한 테스트 통화를 수행합니다.

일반 아날로그 전화기를 사용하여 통화 라우터에 구성된 대로 전화된 라우터의 ISDN 번호로 전화를 겁니다. 호출된 라우터는 SETUP 메시지를 수신해야 합니다(ISDN 통화가 아니므로 나중에 통화가 실패합니다). 호출된 라우터가 SETUP 메시지를 수신하면 호출된 측 ISDN 네트워크가 작동하고 있다고 가정할 수 있습니다. 문제는 로컬 ISDN 네트워크, 대상 ISDN 번호, 장거리 서비스 등일 수 있습니다. 아래 단계를 계속 진행합니다.

- 대상 ISDN 번호가 올바르게 구성되었는지 확인합니다.

Calling Router 컨피그레이션을 확인하고 원격 라우터에 대해 구성된 ISDN 번호가 올바른지 확인합니다. PBX 뒤에 있는 ISDN 회로는 ISDN 번호 앞에 9가 필요한 경우가 많습니다. 또한 통화가 장거리(미국)인 경우 원격 사이트 ISDN 번호 앞에 숫자 1을 포함해야 합니다(일반 전화 장거리 전화 통화와 유사). 예를 들어, 로컬 사이트가 PBX 뒤에 있고 원격 사이트에 대한 통화가 장거리 통화여야 하는 상황을 고려하십시오. 원격 엔드 ISDN 번호는 5551111이며 지역 번호 512 내에 있습니다. 이 경우 PBX의 적절한 숫자 및 장거리 전화 번호는 915125551111입니다.

debug isdn q931 연결 끊기 사유는 통화 실패 원인, 잘못된 원격 ISDN 번호 또는 잘못된 형식의 번호 때문인지를 확인하는 데에도 사용할 수 있습니다. ISDN q931 연결 해제 원인 코드 해석에 대한 자세한 내용은 디버그 isdn q931 연결 해제 원인 코드 이해를 참조하십시오.

잘못된 ISDN 번호로 인한 연결 끊기는 다음과 같이 표시될 수 있습니다.

Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85

Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination

이전에 언급된 Disconnect Cause 코드 문서를 참조하여, 연결 끊기 코드가 비 ISDN 장비에 연결하려고 시도했을 때 발생했는지 확인할 수 있습니다. (예: 아날로그 회선).

잘못된 형식의 번호로 인한 연결 끊기는 다음과 같이 표시될 수 있습니다.

Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86

Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format

(incomplete number)

디버그 isdn q931 연결 끊기 원인 코드 이해 문서를 참조하여, 연결 끊기 코드가 원격 ISDN 번호에 대한 잘못된 형식 때문에 발생했는지 확인할 수 있습니다. 목적지 주소가 인식할 수 없는 형식으로 표시되거나 목적지 주소가 완전하지 않아 연결이 실패합니다.

- 해당하는 경우 장거리 서비스가 활성 상태인지 확인합니다.

로컬 통신 및 장거리 통신 사업자에게 연락하여 서비스가 활성화되었는지 확인해야 합니다. 로컬 텔코에는 아웃바운드 ISDN 장거리 통화가 적절한 장거리 통신 사업자 네트워크로 전환되지 않도록 잘못 구성된 ISDN 회로가 있는 경우가 많습니다. 또한 장거리 공급자 네트워크가 작동하는지 확인해야 합니다.

미국 및 텔코/장거리 통신 사업자가 문제를 해결할 수 없는 상황에서는 PIC(Presubscribed Interexchange Carrier)를 사용할 수 있습니다. PIC 코드는 LEC(Local Exchange Carriers)에 대한 미국 장거리 통신 사업자를 식별하는 7자리 접두사입니다. 이를 통해 고객은 서로 다른 장거리 통신사를 사용하여 별도의 통화를 할 수 있습니다. PIC 코드는 전화를 건 번호에 대한 접두사로 구성됩니다. 대부분의 PIC는 1010xxx 형식입니다. PIC의 숫자 목록은 미국 PIC 코드를 숫자로 나타냅니다.

- 다이얼러 맵 2개 또는 다이얼러 문자열 문 2개를 구성합니다. 원격 B-채널의 ISDN 번호별로 하나씩

각 원격 B-채널에 대해 다이얼러 맵(또는 다이얼러 프로파일을 사용하는 경우 다이얼러 문자열)을 구성하면 텔코가 두 번째 통화를 두 번째 ISDN B-채널로 전환할 수 없는 경우에도 연결을 계속할 수 있습니다.

참고: 지정된 BRI에서 1개의 B 채널만 통화를 수락하는 경우 이 해결 방법이 필요합니다. 이 문제는 멀티링크 연결에서 종종 나타납니다.

샘플 컨피그레이션(다이얼러 맵 사용)이 제공됩니다.

dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111

dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112

!--- dialer map statements for the remote router !--- The two different phone numbers correspond !--- to the b-channels of the remote side. The multiple statements allow !--- the router to dial the second number if the first number is busy.

호출된 라우터가 CONNECT 메시지를 보내지 않습니다.

호출된 라우터가 SETUP 메시지를 수신하지만 CONNECT 메시지로 응답하지 않는 경우, 이는 라우터가 통화 수락을 선택하지 않도록 선택했음을 나타낼 수 있습니다.

호출된 라우터에서 다음 작업을 수행합니다.

- 발신자 ID/DNIS 기반 심사로 인해 통화가 거부되었는지 확인합니다.

발신자 ID 또는 DNIS 기반 심사는 라우터가 유료 요금 없이 특정 통화를 선택적으로 수락하거나 거부할 수 있도록 허용합니다. 발신자 ID 기반 심사와 함께 발신자 라우터가 발신자 번호를 수신합니다(SETUP 메시지에서 수신). 이렇게 하면 라우터가 특정 번호의 통화를 허용하여 보안을 제공할 수 있습니다. DNIS 기반 심사와 함께 발신된 라우터가 전화를 건 번호를 기준으로 수신 통화를 차별화합니다.

CLID/DNIS 기반 심사와 관련하여 기억해야 할 몇 가지 주요 사항은 다음과 같습니다.

1) 텔코는 SETUP 메시지에 적절한 CLID/DNIS 정보를 제공해야 합니다. 라우터에서 발신자 ID 차단을 활성화했지만 라우터로 전달되는 발신자 ID 번호가 없는 경우 라우터에 대한 모든 통화가 "차단됨"으로 표시되고 통화가 수락되지 않습니다.

2) telco에서 제공하는 CLID/DNIS 자릿수의 형식을 확인합니다(debug isdn q931 출력). 예를 들어, 일부 텔코에는 전달된 CLID/DNIS 숫자에 지역 번호가 포함되지만 다른 텔코에는 포함되지 않습니다. CLID/DNIS 컨피그레이션을 적절히 수정합니다.

다음은 실패한 통화의 예입니다. 그러나 텔코가 통화를 거부하는 CLID 번호를 전달하지 않으므로 라우터는 CLID 기반 차단을 사용할 수 있습니다.

maui-nas-08#

05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E

! --- The router receives (RX) a SETUP message

05:46:33:         Bearer Capability i = 0x8890

05:46:33:         Channel ID i = 0x89

05:46:33:         Signal i = 0x40 - Alerting on - pattern 0

05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,

Type:Subscriber(local)

! --- The Called Number (DNIS) is delivered to the router ! --- Note that CLID information is not delivered

05:46:33:         Locking Shift to Codeset 5

05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'

05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE

05:46:33:         Cause i = 0x8095 - Call rejected

! --- Calls is Rejected due to screening

발신자 ID에 대한 자세한 내용은 호출자 ID가 있는 문서 ISDN 인증 및 콜백을 참조하십시오.

- SPID가 올바른지 확인합니다.

show isdn status 명령을 사용하여 호출된 라우터의 SPID가 올바른지 확인합니다. SPID 관련 문제 해결에 대한 자세한 내용은 BRI 문제 해결에 show isdn status 명령 사용을 참조하십시오.

- 전화를 건 회선에 사용 가능한 B 채널이 있는지 확인합니다.

show isdn status 명령을 사용하여 전화를 건 회선에 사용 가능한 채널이 있는지 확인합니다. 사용 가능한 채널이 없는 경우 clear 명령을 사용하여 일부 채널을 해제합니다.

- 여러 BRI를 사용할 수 있는 경우, Telco에서 헌트 그룹에서 구성합니다.

헌트 그룹에 여러 BRI가 있으면 텔코가 해당 라우터의 모든 무료 BRI 회로로 통화를 전환할 수 있습니다. 이 기능에 대해서는 Telco에 문의하십시오.

- 베어러 기능 관련 문제가 있는지 확인합니다.

베어러 기능(또는 베어러 상한)은 지정된 통화의 특성을 정의하는 레이어 3 서비스 표시입니다. 통화의 전달자 상한선은 Q.931 SETUP 메시지에서 통신사에 의해 표시됩니다. 베어러 캡은 64k 음성(아날로그), 56k 데이터 통화 및 64k 데이터 통화를 구분하는 데 자주 사용됩니다. 가장 흔히 볼 수 있는 베어러 상한 메시지와 그 설명은 아래에 나와 있습니다.

베어러 모자

설명

0x8890

ISDN 64K 통화

0x8890218F

ISDN 56K 통화

0x8090A2

음성/음성 통화(U-law)

0x9090A2

음성/음성 통화(u-law) - 3.1kHz 오디오

0x8090A3

음성/음성 통화(A-law)

0x9090A3

음성/음성 통화(A-law) - 3.1kHz 오디오

다음은 ISDN 64k 통화의 예입니다.

Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F

!-- Incoming SETUP messages

Aug  8 18:49:48.246:         Bearer Capability i = 0x8890

!-- The bearer cap indicates the incoming call is ISDN 64k

Aug  8 18:49:48.246:         Channel ID i = 0x89......

통화의 전달자 상한선에 따라 다음 단계를 수행합니다.

베어러 기능: 통화는 ISDN 56K 디지털:

- ISDN 스위치 유형이 올바르게 구성되었는지 확인합니다.

ISDN 스위치 유형은 show isdn status 명령을 사용하여 확인할 수 있습니다. 텔코는 구성해야 하는 스위치 유형을 명시적으로 표시해야 합니다. 때때로(특히 북미 지역의 경우) 텔레코에서 스위치 유형이 "맞춤형" 또는 "국내"임을 나타낼 수 있습니다. 이러한 경우 다음 지침을 사용하여 스위치 유형 컨피그레이션을 결정합니다.

- 사용자 지정: telco가 스위치 유형이 Custom임을 나타내는 경우, 라우터의 스위치 유형을 basic-5ess(5ess 스위치가 있는 BRI), primary-5ess(5ess가 있는 PRI), basic-dms(DMS 스위치가 있는 BRI의 경우) 또는 primary-dms(DMS가 있는 PRI의 경우)로 구성합니다.

- 전국: BRI의 NI-1 표준과 PRI의 NI-2 표준을 따르는 스위치 유형(PRI의 NI-1 표준은 없음) switchtype이 National임을 텔코에서 알리면 Cisco 라우터 컨피그레이션은 basic-ni(BRI의 경우) 또는 primary-ni(PRI의 경우)여야 합니다.

switchtype을 구성하려면 BRI 인터페이스 컨피그레이션 모드에서 isdn switch-type 스위치 유형을 사용합니다. 예제는 ISDN BRI Layer 1 문제 해결을 참조하십시오.

- 다이얼링 측에서 통화 속도/속도가 56k인지 확인합니다. 일부 레거시 ISDN 스위치가 일반 채널을 통과하지 못할 수 있으며 전화를 걸려면 56K로 전화를 걸어야 하기 때문에 이 작업이 필요합니다.

다음 예와 같이 다이얼러 맵 컨피그레이션 명령의 speed 매개 변수를 사용하여 56Kbps의 발신 전화를 걸 수 있습니다.

maui-soho-01(config)#interface bri 0

maui-soho-01(config-if)#dialer map ip 10.1.1.1 name

Maui-NAS-08 speed 56 5551111

!-- The keyword speed 56 sets the outgoing call rate at 56k

다음 예에서는 56Kbps로 발신 전화를 걸도록 Cisco IOS 다이얼러 프로파일을 구성하는 방법을 보여줍니다.

maui-soho-01(config)#interface dialer 1

maui-soho-01(config-if)#dialer string 5558888 class 56k

!-- Use the map-class named "56k" when dialing number 5558888

maui-soho-01(config-if)#exit

maui-soho-01(config)#map-class dialer 56k

!-- map-class named "56k" that was used with the dialer string above

maui-soho-01(config-map-clas)#dialer isdn speed 56

!-- Set the speed of the call to be 56k (default is 64k)

- 수신 측에서 BRI 인터페이스에서 isdn not-end-to-end 56 명령을 구성합니다.

Maui-NAS-08(config)#interface bri 2/0

Maui-NAS-08(config-if)#isdn not-end-to-end 56

ISDN Q.931 베어러 기능 및 기타 IE(Information Element)는 수신 통화의 속도를 결정하는 데 사용되며 대부분의 경우 제대로 작동합니다. 그러나 일부 국가 간 애플리케이션(또는 일부 레거시 스위치로 인해)에서는 수신 통화 설정 메시지가 원래 통화와 일치하지 않는 전달자 기능과 함께 전달됩니다. isdn 'not end-to-end'를 나타내는 메시지가 수신되면 라우터는 엔드 투 엔드가 아닌 Cisco IOS configuration 명령 isdn을 사용하여 수신 베어러 기능을 재정의할 수 있습니다.

베어러 기능은 0x8090A2 또는 0x9090A2입니다. 음성/음성 통화(U-law)

베어러 기능은 0x8090A3 또는 0x9090A3입니다. 음성/음성 통화(A-law)

수신 통화는 64k 아날로그 통화입니다. 모뎀 응용 프로그램의 경우 내부 모뎀으로 통화가 전송되고, 음성 응용 프로그램의 경우 해당 음성 모듈로 통화가 전송될 수 있습니다. 다음 단계를 수행합니다.

1. 수신 측에서 ISDN 물리적 인터페이스(예: 인터페이스 bri 0)에 isdn 수신 음성 모뎀이 구성되었는지 확인합니다.

2. 모뎀 회선에 명령 모뎀이 입력되었는지 확인합니다.

컨피그레이션 예제는 Cisco 3640 BRI를 사용한 모뎀 연결 구성 문서를 참조하십시오.

- DISCONNECT 또는 RELEASE 메시지에서 (Called Router에서 Calling Router로) 전송된 연결 해제 원인 코드를 해석합니다.

Called Router가 CONNECT 메시지를 발신 라우터로 보내지 않을 경우 DISCONNECT 또는 RELEASE 메시지를 다시 보내야 합니다. 이 DISCONNECT 또는 RELEASE 메시지에는 연결 끊기 원인 코드도 포함되어야 합니다. 아래 예에서 연결 해제 원인 코드는 0x8090입니다. 디버그 isdn q931 연결 끊기 원인 코드 이해 문서를 참조하여 연결 끊기 코드를 해석하십시오.

Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8

callref = 0x06

Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing

발신 라우터가 CONNECT 메시지를 수신하지 않습니다.

Called Router가 CONNECT 메시지를 전송하지만 해당 메시지가 Calling Router에서 수신되지 않는 경우 문제가 텔코에 있을 수 있습니다.

- 라우터가 로컬 ISDN 스위치에서 CONNECT_ACK를 수신하는지 확인합니다.

이는 Called Router 근처의 Telco 스위치가 CONNECT 메시지를 수락하고 CONNECT 메시지를 Calling Router에 전달함을 나타냅니다. 통화 실패는 통신 문제 때문일 수 있습니다.

- 추가 문제 해결을 위해 통신사에 문의하십시오.

발신 라우터가 CONNECT를 수신하지만 통화는 여전히 실패합니다.

발신 라우터가 CONNECT 메시지를 수신하면 ISDN 연결이 활성 상태이며 올바르게 작동하고 있음을 나타냅니다. B-Channel이 데이터를 위해 올바르게 매핑되지 않은 데 문제가 있는지 확인하려면 통신사에 문의하십시오. 이 단계를 지난 통화의 모든 실패는 PPP, 인증 또는 IPCP/IP 주소 협상과 같은 더 높은 계층 문제 때문입니다. 추가 ppp 문제 해결을 위해 debug ppp 협상을 사용합니다.

또한 문서 전화 접속 기술을 참조해야 합니다. 추가 PPP 트러블슈팅 기술을 위한 트러블슈팅 기술

관련 정보

- 액세스 기술 지원 페이지

- Technical Support - Cisco Systems