目录

简介

先决条件

要求

使用的组件

规则

故障排除前提条件：激活 ISDN 第 3 层调试

发起 ISDN 呼叫

故障排除概述：症状和解决过程

故障排除：症状和详细解决过程

发起呼叫的路由器没有发送 CONNECT 消息

被呼叫的路由器没有收到 SETUP 消息

被呼叫的路由器没有发送 CONNECT 信息

发起呼叫的路由器没有收到 CONNECT 信息

发起呼叫的路由器收到 CONNECT 但呼叫仍然故障

相关信息

简介

排除ISDN呼叫故障问题时，重要的是要记住：呼叫失败可能归结于以下任何原因：

- 按需拨号路由 (DDR)

- ISDN 第 1 层、第 2 层和第 3 层

- 点对点协议 (PPP)：包括链路控制协议 (LCP)、身份验证或 IP 控制协议 (IPCP) 相关问题。

本文档着重介绍导致呼叫失败的 ISDN 相关问题。本文还假设，您已经验证了电路两端的ISDN第1层和第2层运行正常。欲知验证ISDN第1层和第2层状态的更多信息，参见“使用show isdn status命令排除BRI故障”。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您是在真实网络上操作，请确保您在使用任何命令前已经了解其潜在影响。

规则

有关文档规则的详细信息，请参阅 Cisco 技术提示规则。

故障排除前提条件：激活 ISDN 第 3 层调试

请在两端使用 debug isdn q931 命令来激活 ISDN 第 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 呼叫。两个路由器都将生成 debug isdn q931 消息。

由于ISDN交换机类型的特定要求或者需要其他参数，Q.931交换中可能有许多变化。下图说明了成功的 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

评估主叫和被叫端上的debug isdn q931输出时，请记住以下几点：

- 注意消息的方向。调试指示消息是由路由器生成（由TX ->指示）还是由路由器接收（由RX < — 指示）。 在下例中，第一个消息(连接)由来自ISDN交换机的路由器接收，而第二个信息则有路由器发送(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信息，但发送DISCONNECT而不是CONNECT，则排除主叫路由器而不是ISDN网络的故障。下表是可在呼叫建立和拆卸期间可能查看的Q.931消息列表：

邮件

描述

设置

设置 — 表示设备希望建立第3层呼叫

CALL_PROC

呼叫继续 — 呼叫设置已接收，且正由网络和/或远程设备处理

警报

警报 — 通知网络终端路由器现在正在向用户发出“警报”；通常情况是：电话和警报将是电话听筒的“铃声”。此消息一般与使用电话听筒的设备相连，例如ISDN电话或TA，不用来查看数据呼叫。

连接

连接 — 已接受呼叫

CONNECT_ACK

连接确认 — 设备已收到CONNECT消息。更高层协议（例如，PPP）应该现在开始协商

断开连接

断开连接 — 路由器启动的断开连接消息。此消息通常表示，ISDN电路的功能正常，连接断开是因为某些较高层问题(DDR、PPP等等)。 “三方断开连接握手”将伴随 RELEASE 和 RELEASE_COMP 消息。DISCONNECT 消息还将伴随断开连接原因代码。断开代码也可以用来查明呼叫是从何处断开的(例如呼叫从路由器、本地电信公司交换机，远程电信公司交换机等断开)。 有关详细信息，请参阅了解 debug isdn q931 断开连接原因代码

版本

版本 — 确认断开并继续断开电路。RELEASE 消息夹在 DISCONNECT 消息和 RELEASE_COMP 消息之间。RELEASE 消息可能会伴随断开连接原因代码。断开代码也可以用来查明呼叫是从何处断开的(例如呼叫从路由器、本地电信公司交换机，远程电信公司交换机断开)。 有关详细信息，请参阅了解 debug isdn q931 断开连接原因代码

RELEASE_COMP

释放完成 — 呼叫拆除完成。此消息通常见于以下情况：a) 其中一台路由器发起的正常呼叫终止期间 b) 响应从主叫路由器发出的 SETUP 消息。这通常由交换机和路由器之间的承载能力不匹配引起。RELEASE_COMP 也可能是由于在 SETUP 消息的编码不符合 Q.931 标准或交换机配置时发生协议错误而引起的。RELEASE_COMP 消息可能会伴随断开连接原因代码。断开代码也可以用来查明呼叫是从何处断开的(例如呼叫从路由器、本地电信公司交换机，远程电信公司交换机断开)。 有关详细信息，请参阅了解 debug isdn q931 断开连接原因代码

故障排除概述：症状和解决过程

分析debug isdn q931的输出（如前面部分所描述的），并且在下列中讨论相应的情况。

注意：在本文档中，发起呼叫的路由器称为呼叫路由器，而接受呼叫的路由器称为被叫路由器。

故障排除：症状和详细解决过程

发起呼叫的路由器没有发送 CONNECT 消息

如果主叫路由器不向ISDN网络发送SETUP信息，问题可能与ISDN的第1、2层有关或Dial-on-demand routing (DDR)问题有关，但与第三层无关。

请在主叫路由器上执行以下任务：

- 验证 ISDN 交换机类型是否已正确配置：

ISDN 交换机类型可使用 show isdn status 命令进行验证。电信公司应明确说明需要配置的交换机类型。有时(特别是在北美)，电信公司可能指示交换类型为“自定义”或“国产”。 在这种情况下，请遵循以下指导原则来确定交换机类型配置：

- 自定义:如果电信公司表示其交换机类型为Custom，则将路由器上的交换机类型配置为basic-5ess（对于5ess交换机的BRI）、primary-5ess（对于5ess的PRI）、basic-dms（对于DMS交换机的BRI）或primary-dms（对于DMS的PRI）。

- 全国:交换类型与BRI的NI-2标准和PRI的NI-1标准符合I (PRI没有 NI-1标准)。 如果电信公司指明交换机类型为 national，则 Cisco 路由器配置应为 basic-ni （对于 BRI）或 primary-ni（对于 PRI）。

要配置交换机类型，请在 BRI 接口配置模式下使用 isdn switch-type switch-type 命令。有关示例，请参阅 ISDN BRI 第 1 层故障排除

- 验证主叫路由器上的 ISDN 第 1 层和第 2 层是否正常工作：

您可以使用 show isdn status 命令验证 ISDN 第 1 层和第 2 层是否已启用。请使用所介绍的步骤对 ISDN 第 1 层和第 2 层的相关问题进行故障排除。

- 使用show ip route命令，检验路由器是否有到目的地的路由。

show ip route 命令将指示是否存在通向远程路由器网络的路由。如果路由不存在，使用ip route命令为远程网络添加静态路由。请确保路由指向主叫路由器上的正确接口。

在传统的DDR环境中(例如拨号映射)，下一跳可以是物理接口网络(接口BRI x)，也可以是远程路由器IP地址（也可以配置在拨号映射语句中)。

使用 Dialer Profiles 时，下一跳通常是用于拨出的接口拨号程序 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

在上面的示例中，注意默认路由下一跳是接口拨号程序1(逻辑拨号程序接口可用于此连接)。

- 验证是否可正确标识相关流量。

启动拨号之前，路由器检验流入信息包是否是触发数据流。因此，如果触发数据流不能正确定义，或者如果dialer-list编号(触发数据流定义)不应用物理接口或拨号程序接口(使用dialer-group number命令)，那么路由器可能没有完成拨号。 例如，如果您正在使用ICMP Ping，启动DDR连接，则检验触发数据流定义中是否允许ICMP。

有关详细信息，请参阅使用 DDR Dialer Maps 配置 BRI 到 BRI 的拨号。

- 检查相应的拨号程序字符串（或拨号程序映射）是否包含远程设备的 ISDN 号码。

拨号程序字符串（或拨号程序映射）必须包含远程路由器的 ISDN 号码。例如，

dialer string 5551111

or

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

- 检查DDR配置，并使用debug 拨号器验证路由器正在发送呼叫：

验证 DDR 配置是否正确。请使用文档“拨号技术：概述和解释”获取有关正确配置 DDR 的进一步帮助。

您还应该使用debug dialer命令，检验路由器是否收到触发数据流，并且是否有适当的拨号映射或拨号字符串，来启动拨号。有关详细信息，请参阅上述文档以及拨号技术：故障排除技术。

有关正确配置 DDR 的示例，请参阅以下示例配置：

Dialer Profiles：使用 Dialer Profiles 配置 ISDN DDR 传统 DDR (Dialer Maps)：通过 DDR 拨号映射配置 BRI 之间的拨号

提示：为了进行测试，您可以通过使用isdn call命令（在下一节中介绍）来生成到远程设备的ISDN呼叫，从而消除DDR。如果呼叫成功，您有理由确信ISDN电路正在发挥作用。继续对 DDR 进行故障排除。

- 执行环回测试呼叫

在环回呼叫中，路由器将拨打自己 BRI 的 ISDN 号码。呼叫进入TELCO网云，电信公司将呼叫切换到第二条BRI信道。此呼叫被路由器看作第二条信道上的入呼叫。因此，路由器既发送又接收 ISDN 呼叫。

环回呼叫测试的是路由器发起和终止 ISDN 呼叫的能力。成功的回环呼叫为您提供一个明确的提示，即对电信网云的ISDN电路正确地工作。

下面是一个带注解的成功环回呼叫示例。命令isdn call(在Cisco IOS®软件12.0(3)T中引入)支持传出isdn呼叫，而无需DDR要求，如相关流量和路由。此命令只能用于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 输出时，务必跟踪这些“双重角色”。例如，路由器传输SETUP信息(TX - >设置)，同时接收一个信息(RX < -设置)。 当收到的SETUP消息与入呼叫相关时，传输的设置应该与去话相关。

- 在上面的示例中，我们拨打了第一个 B 信道的号码。然而，电信公司认为第一个B信道繁忙(因为它发出呼叫)，则将呼叫切换到第二个B信道，成功完成连接。然而，由于交换机设法将呼叫分配到第一条信道（忙着处于呼叫)，电信公司交换机的错误配置可能导致环回呼叫故障。 应该由电信公司来解决此问题。不过，作为应急解决方案，您也可以在 isdn call 命令中指定第二个 B 信道号码。

- 如果环回呼叫成功，而到远程终端的呼叫继续出现故障，请与电信公司联系，获得进一步排除BRI电路故障的相关信息。

被呼叫的路由器没有收到 SETUP 消息

如果您指定主叫路由器发送ISDN网层3 SETUP信息，但呼叫路由器不接收该信息，那么问题可能出在呼叫路由器的ISDN L1和L2上，或者可能是电信公司ISDN网云故障。

请在被叫路由器上执行以下任务：

- 验证 ISDN 交换机类型是否已正确配置：

ISDN 交换机类型可使用 show isdn status 命令进行验证。电信公司应明确说明需要配置的交换机类型。有时(特别是在北美)，电信公司可能指示交换类型为“自定义”或“国产”。 在这种情况下，请遵循以下指导原则来确定交换机类型配置：

- 自定义:如果电信公司表明它们的交换机类型是自定义的，请将该路由器的交换机类型配置为basic-5ess (用于带5ess交换机的BRI)，主5ess交换机(用于带6ess的PRI)，basic-dms (用于带DMS交换机的BRI)或主DMS交换机(用于DMS的PRI)。

- 全国:交换类型与BRI的NI-2标准和PRI的NI-1标准符合I (PRI没有 NI-1标准)。 如果电信公司指明交换机类型为 national，则 Cisco 路由器配置应为 basic-ni （对于 BRI）或 primary-ni（对于 PRI）。

要配置交换机类型，请在 BRI 接口配置模式下使用 isdn switch-type switch type 命令。有关示例，请参阅 ISDN BRI 第 1 层故障排除

- 验证主叫路由器上的 ISDN 第 1 层和第 2 层是否正常工作：

您可以使用 show isdn status 命令验证 ISDN 第 1 层和第 2 层是否已启用。使用“采用BRI故障排除的show isdn status命令，排除ISDN第1和第2层相关问题故障”中概述的程序。

- 验证 SPID 本地目录号码 (LDN) 是否已正确配置

某些交换机类型要求对 SPID 和 LDN 进行正确配置以接受传入呼叫。有关详细信息，请参阅“ISDN BRI SPID 故障排除”。

请在主叫路由器上执行以下任务：

- 使用普通模拟电话对远程路由器进行测试呼叫。

使用一般模拟电话，准确拨打实际上配置在主叫路由器上的被叫路由器的ISDN编号。呼叫路由器应该收到SETUP信息(虽然因为它不是ISDN呼叫，以后的呼叫发生故障)。 如果被呼叫的路由器收到SETUP信息，那么我们可以假设被呼叫端ISDN的网络在工作。问题能可能出在本地端 ISDN 网络、目标 ISDN 号码、长途服务，等等。使用以下步骤继续操作。

- 确保目标 ISDN 号码已正确配置：

检查主叫路由器配置并且验证为远程路由器配置的ISDN编号是正确的。PBX 后面的 ISDN 电路通常要求在 ISDN 号码之前设置一个 9。如果是长途呼叫（在美国)，那么您应当在远程站点ISDN编号前添加数字1 (类似于普通的长途电话拨打)。 例如，考虑本地站点位于PBX之后的什么位置时，对远程站点的呼叫需要是长途呼叫。区号512内的远程终端ISDN号码是5551111。在这种情况下，包括PBX和长途的适当数字，拨打的号码是915125551111。

也可以使用debug isdn q931断线原因，确定呼叫失败是否归结于不正确的远程ISDN号码或者归结于不适当的格式化号码。欲知关于解释ISDN Q931断开原因代码的更多信息，请参见了解debug 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

参见“以前参考的断开原因代码”文件，我们可以确定断开代码是否由企图连接到非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)

参见“了解debug isdn q931断开原因代码”文件，我们可以确定断开代码是否由远程ISDN号码的无效格式引起。连接发生故障是因为目的地址是用无法识别的格式提交(到交换机)的，或者目的地址不完整。

- 如果适用，请确定长途服务是否已启用：

您应该与您的本地电信公司和长途电信运营商联系，检验服务是否激活。本地Telco经常错误配置ISDN电路，这样出局ISDN长途呼叫不会通过被切换到适当的长途提供商网络上。您还应验证长途电信运营商网络是否正常工作。

在美国和电信公司/长距离提供商无法纠正问题的环境，您也许希望使用预定的内部交换载体(PIC)。PIC 代码是 7 位数前缀，用于向本地交换运营商 (LEC) 标识美国的长途电信运营商。 这让客户可以针对不同的呼叫使用不同的长途电信运营商。PIC编码配置作为对呼叫号码的前缀。多数PICs是格式1010xxx的。有关 PIC 的数字列表，请参阅美国 PIC 代码（用数字表示）

- 配置两个拨号程序映射或两个拨号程序字符串语句；每个远程 B 信道的 ISDN 号码均使用其中的一个：

为每条远程B信道配置一个拨号映射(如果使用Dialer Profile，则是拨号程序串)，与呼叫路由器一样，即使电信公司不能在ISDN B信道交换第二呼叫仍能保持该路径的连接。

注意：如果仅1个B信道在给定BRI上接受呼叫，则需要此解决方法。此问题常见于多链路连接。

下面提供的是一个配置示例（使用拨号程序映射）：

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) 检查电信公司提供的CLID/DNIS数字的格式(在debug isdn q931命令的输出中)。 例如，一些Telco在提供的CLID/DNIS数字中包括区域代码，而其它Telco不包括。必要时可更正任何 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的更多信息，参见本文的“ISDN认证和带有主叫ID的回呼”。

- 验证 SPID 是否正确：

使用show isdn status命令，检验被叫路由器上的SPID是否正确。有关 SPID 相关问题故障排除的详细信息，请参阅使用 show isdn status 命令进行 BRI 故障排除。

- 确保拨号的电路上存在可用的 B 信道：

使用show isdn status命令，检查拨号电路上是否有任何可用信道。如果没有可用的信道，使用clear命令释放一些信道。

- 如果存在多个可用的 BRI，请让电信公司将它们配置在一个寻线组中：

Hunt组中有多个BRI接口，允许电信公司把呼叫切换到该路由器上的任何自由BRI电路。要了解此功能，请与电信公司联系。

- 检查您是否遇到与承载能力相关的问题：

承载能力(或承载容量)是第3层服务的显示，定义了特定呼叫的特性。电信公司在 Q.931 SETUP 消息中对呼叫承载能力进行了说明。经常使用承载容量，来区分64k语音(模拟)，56k数据呼叫和64k数据呼叫。最常见的承载能力消息及其说明如下：

承载能力

描述

0x8890

ISDN 64K 呼叫

0x8890218F

ISDN 56K 呼叫

0x8090A2

话音/语音呼叫 (u-law)

0x9090A2

话音/语音呼叫 (u-law) - 3.1 kHz 音频

0x8090A3

话音/语音呼叫 (A-law)

0x9090A3

话音/语音呼叫 (A-law) - 3.1 kHz 音频

下面是一个 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......

根据呼叫的承载能力，执行以下步骤：

承载能力为 0x8890218F：呼叫为 ISDN 56K（数字线路）：

- 验证 ISDN 交换机类型是否已正确配置：

ISDN 交换机类型可使用 show isdn status 命令进行验证。电信公司应明确说明需要配置的交换机类型。有时(特别是在北美)，电信公司可能指示交换类型为“自定义”或“国产”。 在这种情况下，请遵循以下指导原则来确定交换机类型配置：

- 自定义:如果电信公司表明它们的交换机类型是自定义的，请将该路由器的交换机类型配置为basic-5ess (用于带5ess交换机的BRI)，主5ess交换机(用于带6ess的PRI)，basic-dms (用于带DMS交换机的BRI)或主DMS交换机(用于DMS的PRI)。

- 全国:交换类型与BRI的NI-2标准和PRI的NI-1标准符合I (PRI没有 NI-1标准)。 如果电信公司指明交换机类型为 national，则 Cisco 路由器配置应为 basic-ni （对于 BRI）或 primary-ni（对于 PRI）。

要配置交换机类型，请在 BRI 接口配置模式下使用 isdn switch-type switch type 命令。有关示例，请参阅 ISDN BRI 第 1 层故障排除

- 在拨号端，请验证呼叫的速度/速率是否为 56k。这是必要的，因为一些传统ISDN交换机或许不能通过无干扰信道，并且可能迫使您发出56Kbps速率呼叫，获得通过。

使用dialer map configuration命令上的速度参数，发出56 Kbps速率去话，如以下示例所示：

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

以下示例说明了如何配置Cisco IOS拨号器配置文件，发送56 Kbps去话：

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）用来决定呼入呼叫的速度。在多数情况下操作正确。然而，在一些国家（地区）对国家（地区）的应用程序(或由于一些传统交换机)中，输入呼叫设置消息提供与原始呼叫不匹配的承载能力。如果接收到显示isdn不是“端到端'的信息，路由器可以使用Cisco IOS配置命令“ isdn not end-to-endisdn“改写接收的承载能力。

承载能力为 0x8090A2 或 0x9090A2：话音/语音呼叫 (u-law)

承载能力为 0x8090A3 或 0x9090A3：话音/语音呼叫 (A-law)

传入呼叫为 64k 模拟呼叫。在调制解调器应用中，该呼叫将发送到内部的调制解调器上；而在语音应用中，该呼叫则发送到适当的语音模块上。请执行下列步骤：

1. 在接收端，请验证 ISDN 物理接口（例如，interface bri 0）是否已配置 isdn incoming-voice modem。

2. 验证调制解调器线路是否设置了 modem inout 命令。

有关示例配置，请参阅文档使用 Cisco 3640 BRI 配置调制解调器连通性

- 解释DISCONNECT 或 RELEASE信息中发送(从呼叫路由器到主叫路由器)断开原因的编码。

如果被叫路由器不向主叫路由器发送CONNECT信息，应该退还DISCONNECT或RELEASE 信息。此 DISCONNECT 或 RELEASE 消息也应包括断开连接原因代码。在以下示例中，断开原因代码为0x8090。请参阅文档了解debug 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 信息

如果被叫路由器发送CONNECT信息，但主叫路由器没有收到该消息，那么问题很可能与电信公司有关。

- 确定路由器是否从本地 ISDN 交换机接收了 CONNECT_ACK：

这表示靠近被叫路由器的电信公司交换机接受了CONNECT信息，并把CONNECT信息传递给主叫路由器。呼叫失败可能是电信公司的问题。

- 如需进一步的故障排除，请与电信公司联系。

发起呼叫的路由器收到 CONNECT 但呼叫仍然故障

如果主叫路由器收到一条CONNECT信息，那表明ISDN连接是激活的，并正常工作。联系电信公司，确定B信道是否有问题，数据映射是否适当。任何通过此阶段的呼叫故障都可以归结为更高层的问题，如PPP、认证或者IPCP/IP 地址协商产生的问题。请使用 debug ppp negotiation 进行进一步的 ppp 故障排除。

您还应参阅文档拨号技术：故障排除技术，了解更多的 PPP 故障排除技术。

相关信息

- 接入技术支持页

- 技术支持 - Cisco Systems