使用debug isdn q931命令排除ISDN BRI第3層故障

下載選項

  • PDF     (472.6 KB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (167.7 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (197.8 KB)
    在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視
已更新: 2010 年 2 月 4 日
文件 ID:9495

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

在排除ISDN呼叫失敗問題時，請務必記住呼叫可能由於以下任何原因而失敗：

  • 按需撥號路由 (DDR)

  • ISDN第1、2和3層

  • 點對點通訊協定(PPP):包括連結控制通訊協定(LCP)、驗證或IP控制通訊協定(IPCP)相關問題。

本文檔專門介紹導致呼叫失敗的ISDN相關問題。本檔案還假設您已驗證電路兩端的ISDN第1層和第2層工作正常。有關驗證ISDN第1層和第2層狀態的詳細資訊，請參閱使用show isdn status命令進行BRI故障排除。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

故障排除先決條件：啟用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事務。

isdn_q931_ts_1.gif

註：以下調試輸出行的某些行被分成多行進行列印。

通話路由器 被叫路由器 
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)，而路由器傳送第二個訊息(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消息：

消息 說明
設定 Setup — 表示裝置希望建立第3層呼叫
CALL_PROC 呼叫繼續 — 網路和/或遠端裝置已收到並正在處理呼叫設定
警報 警報 — 通知網路終端路由器現在正在「警報」使用者；對於電話來說通常是這種情況，並且警報是聽筒上的「響鈴」。此消息通常與使用話筒（例如ISDN電話或TA）的裝置相關聯，通常不會在資料呼叫中顯示。
CONNECT Connect — 呼叫被接受
CONNECT_ACK 連線確認 — 裝置已收到CONNECT消息。更高層的協定(例如PPP)現在應開始協商
斷開連線 斷開連線 — 路由器啟動斷開連線消息。此訊息通常表示ISDN電路運作正常，且結束通話是某些較高層問題（DDR、PPP等）的結果。 三次斷開握手將伴隨RELEASE和RELEASE_COMP消息。DISCONNECT消息還附帶一個斷開原因代碼。此斷開代碼可用於查明呼叫斷開的位置（例如，呼叫與路由器、本地電信交換機、遠端電信交換機等斷開連線）。 有關詳細資訊，請參閱了解調試isdn q931斷開連線原因代碼
版本 Release — 確認DISCONNECT並繼續電路斷開。RELEASE消息夾在DISCONNECT和RELEASE_COMP消息之間。RELEASE消息可能附帶斷開原因代碼。此斷開代碼還可用於查明呼叫斷開的位置（例如，呼叫與路由器、本地電信交換機、遠端電信交換機斷開）。 如需更多詳細資訊，請參閱瞭解debug isdn q931結束通話原因代碼
RELEASE_COMP 釋放完成 — 呼叫終止已完成。此訊息常見於：a)在由其中一個路由器發起的正常呼叫終止期間b)響應來自呼叫路由器的SETUP消息。這通常是因為交換機和路由器之間的承載能力不匹配造成的。如果SETUP消息的編碼不符合Q.931標準或交換機的配置，則協定錯誤也會導致RELEASE_COMP。 RELEASE_COMP消息可能會附帶斷開連線原因代碼。此斷開代碼還可用於查明呼叫斷開的位置（例如，呼叫與路由器、本地電信交換機、遠端電信交換機斷開）。 有關詳細資訊，請參閱瞭解debug isdn q931斷開連線原因代碼

故障排除概述：症狀和解析程式

如前幾節所述，分析debug isdn q931輸出，並繼續處理下面討論的相應症狀。

註：在本文檔中，發起呼叫的路由器稱為呼叫路由器，而接受呼叫的路由器稱為「被叫路由器」。

疑難排解:故障現象和詳細解決過程

呼叫路由器不傳送SETUP消息

isdn_q931_ts_table1.gif

如果呼叫路由器不向ISDN網路傳送SETUP消息，則問題可能與ISDN第1層、第2層或按需撥號路由(DDR)問題有關，與第3層無關

在呼叫路由器上執行以下任務：

  • 驗證ISDN交換器型別是否正確設定：

    可以使用show isdn status指令驗證ISDN交換器型別。電信公司應明確指出需要配置的交換機型別。有時（特別是在北美），電信公司可能會指示交換機型別為「custom」或「national」。 在這種情況下，請使用以下准則來確定交換機型別配置：

    • 自定義:如果電信公司指示其交換機型別是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標準）。 如果電信公司通知您交換機型別為National，則思科路由器配置應為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環境中（例如，撥號器對應），下一跳應是物理介面網路(interface BRI x )或遠端路由器IP位址(也應在撥號器對應語句中設定)。

    使用Dialer Profiles時，下一個躍點通常是用於撥出的interface Dialer 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

    在上方示例中，請注意，預設路由下一跳是interface Dialer 1（此連線的邏輯撥號程式介面）。

  • 驗證相關流量是否正確識別。

    路由器在開始撥號之前會檢查來信資料包是否為相關流量。因此，如果相關流量定義錯誤，或者未將dialer-list 編號（相關流量定義）應用於物理介面或撥號器介面(使用dialer-group number 命令)，則路由器可能不會撥號。 例如，如果您使用ICMP ping來發起DDR連線，請確認相關流量定義中是否允許ICMP。

    有關詳細資訊，請參閱使用DDR撥號器對映配置BRI到BRI撥號。

  • 檢查相應的dialer string(或dialer map)是否包括遠端裝置的ISDN號碼。

    撥號器字串（或撥號器對映）必須包含遠端路由器的ISDN編號。例如， 

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

  • 檢查DDR配置並使用debug dialer驗證路由器是否正在發起呼叫：

    驗證DDR配置是否正確。使用文檔Dialup Technology:有關正確DDR配置的進一步幫助的概述和說明。

    您還應該使用命令debug dialer來驗證路由器是否收到感興趣的流量，以及是否具有適當的撥號器對映或撥號器字串來啟動撥號。請參閱上述檔案以及撥號技術：疑難排解技術，瞭解詳細資訊。

    有關正確的DDR配置的示例，請參閱以下示例配置：

    撥號器設定檔：使用撥號程式配置檔案配置ISDN DDR（撥號程式對映）：使用DDR撥號器對映配置BRI到BRI撥號

    提示：出於測試目的，您可以使用isdn call命令（下一節中介紹）生成對遠端裝置的ISDN呼叫，從而消除DDR。如果呼叫成功，則可以合理地確定ISDN電路工作正常。繼續排除DDR故障

  • 執行環回測試呼叫

    在環回呼叫中，路由器撥打自己的BRI的ISDN號碼。呼叫繼續到電信雲，電信將呼叫切換到第二個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輸出時，請務必跟蹤這些「雙重角色」。例如，路由器傳送設定訊息(TX -> SETUP)並接收一則訊息(RX <- SETUP)。 傳輸的SETUP應與傳出呼叫關聯，而接收的SETUP消息與傳入呼叫關聯。

  • 在上例中，我們撥打了第一個B通道的號碼。但是，電信公司認識到第一個B通道忙（因為它正在進行呼叫），將呼叫切換到第二個B通道，並且連線成功完成。但是，由於交換機嘗試將呼叫分配給第一個通道（該通道正忙於進行呼叫），電信交換機中的錯誤配置可能會導致環回呼叫失敗。 電信公司應更正此問題。但是，作為一種解決方法，請在isdn call命令中指定第二個B通道編號。

  • 如果環回呼叫成功且對遠端端的呼叫繼續失敗，請與電信公司聯絡，以獲得有關BRI電路的進一步故障排除幫助。

被叫路由器沒有收到SETUP消息

isdn_q931_ts_table2.gif

如果您確定呼叫路由器傳送了ISDN第3層SETUP消息，但被呼叫路由器沒有收到該消息，則問題可能是被呼叫路由器上的ISDN第1層和第2層，或者可能是電信ISDN雲的問題。

在被叫路由器上執行以下任務：

  • 驗證ISDN交換器型別是否正確設定：

    可以使用show isdn status指令驗證ISDN交換器型別。電信公司應明確指出需要配置的交換機型別。有時（特別是在北美），電信公司可能會指示交換機型別為「custom」或「national」。 在這種情況下，請使用以下准則來確定交換機型別配置：

    • 自定義:如果電信公司指示其交換機型別是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標準）。 如果電信公司通知您交換機型別為National，則思科路由器配置應為basic-ni（對於BRI）或primary-ni（對於PRI）。

    要配置switchtype，請在BRI介面配置模式下使用isdn switch-type 命令。如需範例，請參閱疑難排解ISDN BRI第1層

  • 驗證呼叫路由器上的ISDN第1層和第2層是否正常工作：

    您可以使用命令show isdn status驗證ISDN第1層和第2層是否處於啟用狀態。使用使用show isdn status命令進行BRI故障排除中概述的程式，對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後面，而遠端站點呼叫需要是長途呼叫的情況。遠端端ISDN號碼在區號512內為5551111。在這種情況下，包括PBX和長途的相應數字，所撥號碼為915125551111。

    debug isdn q931斷開原因還可用於確定呼叫失敗的原因有哪些：是因為、遠端ISDN號碼不正確，還是因為號碼格式不正確。請參閱瞭解debug 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

    參照前面提到的「斷開原因代碼」文檔，我們可以確定斷開代碼是由嘗試連線到非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號碼的無效格式造成的。連線失敗，因為目標地址以無法識別的格式呈現（呈現在交換機上），或者目標地址不完整。

  • 如果適用，確定長途服務是否處於活動狀態：

    您應該聯絡當地電信公司和長途提供商，確認服務已啟用。通常，本地電信公司的ISDN電路配置錯誤，以至於出站ISDN長途呼叫不會切換到相應的長途提供商網路。您還應該驗證長途提供商網路是否正常工作。

    在美國以及電信/長途提供商無法糾正問題的情況下，您可能希望使用預訂購的網際網路交換運營商(PIC)。PIC碼是7位的字首，用於識別美國到本地交換載波(LEC)的長途載波。 這使客戶可以使用不同的長途電信公司進行單獨呼叫。PIC代碼被配置為被叫號碼的字首。大多數PIC的格式為1010xxx。有關PIC的數字清單，請參閱美國PIC代碼， /images/exit.gif

  • 配置兩個撥號器對映或兩個撥號器字串語句；每個遠端B通道的ISDN號碼各一個：

    為每個遠端B通道配置撥號器對映（如果使用撥號器配置檔案，則為撥號器字串）允許連線繼續進行，即使電信公司無法將第二個呼叫切換到第二個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消息

isdn_q931_ts_table3.gif

如果被叫路由器收到SETUP消息但未使用CONNECT消息進行響應，則這可能表示路由器（由於某些不確定原因）選擇不接受該呼叫。

在被叫路由器上執行以下任務：

  • 檢查呼叫是否由於基於呼叫者ID/DNIS的遮蔽而被拒絕：

    呼叫者ID或基於DNIS的遮蔽允許路由器選擇性地接受或拒絕特定呼叫，而不會產生長途話費。通過基於呼叫者ID的篩選，被呼叫路由器收到（在SETUP消息中）呼叫方的號碼。這允許路由器允許來自特定號碼的呼叫，從而提供了一定的安全性。通過基於DNIS的篩選，被叫路由器根據撥出的號碼來區分來電。

    關於基於CLID/DNIS的篩查，需要記住幾個要點：

    1)電信公司必須在SETUP消息中提供相應的CLID/DNIS資訊。如果在路由器上啟用呼叫者ID篩選，但沒有將呼叫者ID數字傳遞到路由器，則所有到路由器的呼叫都將被「篩選」，不會接受任何呼叫。

    2)檢查電信公司提供的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是否正確。請參閱使用show isdn status命令進行BRI故障排除以瞭解更多有關Spid相關問題的故障排除資訊。

  • 確保所撥電路上有可用的B通道：

    使用show isdn status命令檢查所撥電路上是否有任何可用通道。如果沒有可用的通道，請使用clear命令釋放一些通道。

  • 如果有多個BRI可用，讓電信公司在一個尋線組中配置它們：

    在尋線組中有多個BRI允許電信公司將呼叫切換到該路由器上任何空閒的BRI電路。聯絡電信公司獲取此功能。

  • 檢查您是否遇到與承載能力相關的問題：

    承載能力（或承載帽）是定義給定呼叫特徵的第3層服務指示。呼叫的承載上限由telco在Q.931 SETUP消息中指示。承載帽通常用於區分64k語音（模擬）、56k資料呼叫和64k資料呼叫。最常見的持有者上限消息及其說明如下：

    持有人Cap 說明
    0x8890 ISDN 64K呼叫
    0x8890218F ISDN 56K呼叫
    0x8090A2 語音/語音呼叫(u-law)
    0x9090A2 語音/語音呼叫(u-law)- 3.1 kHz音訊
    0x8090A3 語音/語音呼叫(A-law)
    0x9090A3 語音/語音呼叫（A律） — 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交換器型別是否正確設定：

      可以使用show isdn status指令驗證ISDN交換器型別。電信公司應明確指出需要配置的交換機型別。有時（特別是在北美），電信公司可能會指示交換機型別為「custom」或「national」。 在這種情況下，請使用以下准則來確定交換機型別配置：

      • 自定義:如果電信公司指示其交換機型別是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標準）。 如果電信公司通知您交換機型別為National，則思科路由器配置應為basic-ni（對於BRI）或primary-ni（對於PRI）。

      要配置switchtype，請在BRI介面配置模式下使用isdn switch-type 命令。如需範例，請參閱疑難排解ISDN BRI第1層

    • 在撥號端，確認呼叫的速度/速率是56k。這是必要的，因為一些舊式ISDN交換機可能沒有通過清晰的通道，可能迫使您在56K進行呼叫以通過。

      使用dialer map配置命令上的speed引數以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「not end-to-end」的消息，路由器可以使用Cisco IOS配置命令isdn not end-to-end覆蓋收到的承載能力。

      承載能力是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消息還應包含斷開原因代碼。在以下示例中，斷開連線原因代碼為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消息

isdn_q931_ts_table4.gif

如果被叫路由器傳送了CONNECT消息，但主叫路由器沒有收到該消息，則問題很可能出在電信公司。

  • 判斷路由器是否從本地ISDN交換器收到CONNECT_ACK:

    這表示被呼叫路由器附近的電話公司交換機接受了CONNECT消息並且正在將CONNECT消息傳遞給呼叫路由器。呼叫失敗可能是電信問題。

  • 聯絡電信公司進行進一步的故障排除。

呼叫路由器收到CONNECT，但呼叫仍然失敗

如果呼叫路由器收到CONNECT消息，則表明ISDN連線處於活動狀態且運行正常。聯絡電信公司，確定是否有資料的B通道沒有正確對映的問題。如果呼叫經過此階段，則任何失敗都是由更高層問題（如PPP、身份驗證或IPCP/IP地址協商）引起的。使用debug ppp negotiation進一步排除ppp故障。

您還應參閱撥號技術：故障排除技術，瞭解進一步的PPP故障排除技術。

相關資訊

修訂記錄

修訂 發佈日期 意見
1.0
04-Feb-2010
初始版本

這份文件是否有所幫助？

Feedback意見

讓思科協助您

本文件適用於這些產品