Risoluzione dei problemi di ISDN BRI layer 3 con il comando debug isdn q931

Introduzione

Per risolvere i problemi relativi agli errori delle chiamate ISDN, è importante tenere presente che la chiamata potrebbe non riuscire per uno dei motivi seguenti:

• Routing su chiamata su richiesta (DDR)

• ISDN layer 1, 2 e 3

• Protocollo PPP (Point-to-Point Protocol): compresi i problemi relativi al protocollo LCP (Link Control Protocol), all'autenticazione o al protocollo IPCP (IP Control Protocol).

Nel documento si fa riferimento in particolare ai problemi relativi alle reti ISDN che causano errori nelle chiamate. per le successive spiegazioni, si presume che gli ISDN layer 1 e 2 su entrambe le estremità del circuito siano stati verificati. Per ulteriori informazioni sulla verifica dello stato dei layer 1 e 2 ISDN, fare riferimento a Uso del comando show isdn status per la risoluzione dei problemi BRI.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Prerequisiti per la risoluzione dei problemi: Attivazione dei debug ISDN Layer 3

Per attivare i debug ISDN Layer 3, usare il comando debug isdn q931 su entrambe le estremità. Inoltre, su entrambi i router devono essere abilitati i timestamp dei millisecondi per i debug. I timestamp sono necessari per fornire un input relativo al processo di risoluzione dei problemi.

Nota: attivare i timestamp in millisecondi per i debug utilizzando i seguenti comandi:

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

Per ulteriori informazioni sui comandi di debug, consultare le informazioni importanti sui comandi di debug.

Avvio della chiamata ISDN

Generare un ping ICMP sull'indirizzo IP del router remoto. In questo modo si avvia una chiamata ISDN al router. Entrambi i router genereranno messaggi debug isdn q931.

Gli scambi Q.931 possono presentare molte variazioni dovute a requisiti specifici per i tipi di switch ISDN o ai casi in cui sono richiesti parametri aggiuntivi. Il diagramma seguente mostra le transazioni comuni del Q.931 durante la corretta configurazione di una chiamata ISDN.

Nota: alcune delle seguenti righe di output di debug sono suddivise in più righe a scopo di stampa.

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 

Quando si valuta l'output debug isdn q931 sulla chiamata e sulle terminazioni chiamate, tenere presente quanto segue:

• Prestare attenzione alla direzione dei messaggi. I debug indicano se i messaggi sono stati generati dal router (indicato da TX ->) o se sono stati ricevuti dal router (indicato da RX <—). Nell'esempio seguente, il router riceve il primo messaggio (CONNECT) dallo switch ISDN, mentre il secondo messaggio (CONNECT_ACK) viene inviato dal router:

  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
  
  

  È possibile identificare l'origine del problema seguendo la direzione di un particolare messaggio e la risposta. Ad esempio, se il router riceve in modo imprevisto un messaggio RELEASE dallo switch telco ISDN, verrà reimpostata anche la fine della connessione. Ciò indica che il problema è causato dallo switch ISDN telco o dal router remoto

• Verificare che il messaggio ricevuto o inviato sia quello previsto. Ad esempio, se la parte chiamata riceve un messaggio SETUP ma invia un messaggio DISCONNECT anziché un messaggio CONNECT, risolvere il problema del router chiamato e non della rete ISDN. Nella tabella seguente è riportato un elenco di possibili messaggi Q.931 visualizzati durante la definizione e la disinstallazione delle chiamate:

Panoramica della risoluzione dei problemi: Procedura per i sintomi e la risoluzione

Analizzare l'output debug isdn q931 come descritto nelle sezioni precedenti e procedere con il sintomo appropriato descritto di seguito.

Nota: in questo documento, il router che inizia la chiamata è detto router chiamante, mentre il router che accetta la chiamata è detto router chiamato.

Risoluzione dei problemi: Sintomo e procedura dettagliata di risoluzione

Il router chiamante non invia un messaggio SETUP

Se il router chiamante non invia un messaggio di installazione alla rete ISDN, il problema potrebbe essere correlato ai livelli ISDN 1, 2 o al routing DDR (Dial-on-Demand Routing) e non al livello 3

Eseguire le attività seguenti sul router chiamante:

• Verificare che il tipo di switch ISDN sia configurato correttamente:

  Il tipo di switch ISDN può essere verificato con il comando show isdn status. Il telecomando deve indicare esplicitamente il tipo di switch da configurare. Occasionalmente (specialmente in Nord America) il telco può indicare che il tipo di commutatore è "personalizzato" o "nazionale". In questi casi, utilizzare le seguenti linee guida per determinare la configurazione dello switchtype:

  • Personalizzato: Se il messaggio telco indica che il tipo di switch è Custom, configurare il tipo di switch sul router come basic-5ess (per BRI con switch 5ess), primary-5ess (per PRI con 5ess), basic-dms (per BRI con switch DMS) o primary-dms (per PRI con DMS).

  • Nazionale: Tipo di switch conforme allo standard NI-1 per BRI e NI-2 per PRI (non esiste uno standard NI-1 per PRI). Se il messaggio telco informa che lo switch è di tipo nazionale, la configurazione del router Cisco deve essere di tipo Basic-In (per BRI) o primary-In (per PRI).

  Per configurare il tipo di switch, usare il comando isdn switch-type switch-type nella modalità di configurazione dell'interfaccia BRI. Per un esempio, fare riferimento alla sezione Risoluzione dei problemi di ISDN BRI layer 1

• Verificare che i livelli ISDN 1 e 2 sul router chiamante funzionino:

  Per verificare che i livelli ISDN 1 e 2 siano attivi, usare il comando show isdn status. Utilizzare la procedura descritta in per risolvere i problemi relativi al layer 1 e 2 ISDN.

• Utilizzare il comando show ip route per verificare che il router abbia un percorso verso la destinazione.

  Il comando show ip route indicherà se è disponibile una route alla rete del router remoto. Se la route non esiste, utilizzare il comando ip route per aggiungere una route statica per la rete remota. Verificare che il percorso punti all'interfaccia corretta sul router chiamante.

  In un ambiente DDR legacy (ad esempio, le mappe dialer) l'hop successivo deve essere la rete dell'interfaccia fisica (interfaccia BRI x ) o l'indirizzo IP del router remoto (che dovrebbe essere stato configurato anche nell'istruzione dial map).

  Con i profili dialer, l'hop successivo è in genere l'interfaccia Dialer x utilizzata per il dialout. Ad esempio,

  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
  

  Nell'esempio precedente, si noti che il percorso predefinito dell'hop successivo è interface Dialer 1 (l'interfaccia di connessione logica per questa connessione).

• Verificare che il traffico interessante sia identificato correttamente.

  Il router verifica che un pacchetto in arrivo costituisca traffico interessante prima di avviare la composizione. Di conseguenza, il router potrebbe non comporre il numero se il traffico di interesse non è definito correttamente o se il numero dialer-list (la definizione del traffico di interesse) non è applicato all'interfaccia fisica o all'interfaccia di composizione (usando il comando dialer-group number). Ad esempio, se si utilizza un ping ICMP per avviare la connessione DDR, verificare che l'ICMP sia autorizzato nella definizione del traffico interessante.

  Per ulteriori informazioni, fare riferimento a Configurazione di accesso remoto BRI-BRI con mappe dialer DDR.

• Verificare se la stringa di connessione appropriata (o la mappa di connessione) include il numero ISDN della periferica remota.

  La stringa o la mappa del dialer deve includere il numero ISDN del router remoto. Ad esempio,

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

• Controllare la configurazione DDR e utilizzare la finestra di dialogo di debug per verificare che il router stia iniziando la chiamata:

  Verificare che la configurazione DDR sia corretta. Utilizzare la tecnologia di connessione remota del documento: Panoramiche e spiegazioni per ulteriore assistenza sulla corretta configurazione DDR.

  È inoltre consigliabile utilizzare il comando debug dialer per verificare che il router riceva traffico interessante e disponga della mappa o della stringa di composizione appropriata per avviare la composizione. Per ulteriori informazioni, fare riferimento al documento e a Tecnologia di connessione remota: Tecniche di risoluzione dei problemi per ulteriori informazioni.

  Per esempi sulla corretta configurazione DDR, fare riferimento alla configurazione di esempio seguente:

  Profili dialer: Configurazione di DDR ISDN con profili dialer DDR legacy (mappe dialer): Configurazione di BRI-to-BRI Dialup con mappe dialer DDR

  Suggerimento: a scopo di test, è possibile eliminare il DDR utilizzando il comando isdn call (descritto nella sezione successiva) per generare una chiamata ISDN al dispositivo remoto. Se la chiamata ha esito positivo, si è ragionevolmente certi che il circuito ISDN funzioni correttamente. Continua la risoluzione dei problemi di DDR

• Esegui una chiamata di test di loopback

  In una chiamata di loopback, il router compone il numero ISDN del proprio BRI. La chiamata procede al cloud di telco, dove il telefono passa al secondo canale BRI. Questa chiamata viene ora vista dal router come una chiamata in arrivo sul secondo canale. Pertanto, il router invia e riceve la chiamata ISDN.

  Una chiamata loopback verifica la capacità del router di avviare e terminare una chiamata ISDN. Una chiamata di loopback riuscita fornisce una forte indicazione che il circuito ISDN al telco cloud sta funzionando correttamente.

  Di seguito è riportato un esempio annotato di una chiamata di loopback riuscita. Il comando isdn call (introdotto nel software Cisco IOS® versione 12.0(3)T) consente di effettuare chiamate isdn in uscita senza richiedere i requisiti DDR, ad esempio il traffico e le route interessanti. Questo comando può essere usato solo per verificare il funzionamento del circuito ISDN e non può essere usato per trasmettere il traffico o per sostituire una configurazione DDR corretta. Questo comando consente di verificare il funzionamento del circuito ISDN, in particolare del layer 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

Note:

• Durante la chiamata di loopback, il router svolge sia il ruolo di router chiamato sia quello di router chiamante (anche se su canali B diversi). È importante tenere traccia di questi "ruoli doppi" quando si interpreta l'output debug isdn q931. Ad esempio, il router trasmette un messaggio di configurazione (TX -> SETUP) e ne riceve uno anche (RX <- SETUP). L'impostazione trasmessa deve essere associata alla chiamata in uscita mentre il messaggio SETUP ricevuto è associato alla chiamata in arrivo.

• Nell'esempio precedente è stato composto il numero per il primo canale B. Tuttavia, il telco, riconoscendo che il primo canale B era occupato (dal momento che stava effettuando la chiamata), ha cambiato la chiamata al secondo canale B e la connessione è stata completata correttamente. Tuttavia, una configurazione errata nello switch telco può ostacolare la riuscita della chiamata di loopback, in quanto lo switch cerca di assegnare la chiamata al primo canale (occupato nella chiamata). Il telco dovrebbe risolvere questo problema. Tuttavia, come soluzione alternativa, specificare il secondo numero del canale B nella chiamata del comando isdn.

• Se la chiamata di loopback ha esito positivo e la chiamata al terminale remoto continua a non riuscire, contattare il supporto tecnico per ulteriore assistenza nella risoluzione del problema con il circuito BRI.

Il router chiamato non riceve un messaggio di installazione

Se si determina che il router chiamante invia un messaggio di installazione del layer 3 ISDN, ma che il router chiamato non lo riceve, il problema potrebbe riguardare i layer 1 e 2 ISDN sul router chiamato o il cloud telco ISDN.

Eseguire le attività seguenti sul router chiamato:

• Verificare che il tipo di switch ISDN sia configurato correttamente:

  Il tipo di switch ISDN può essere verificato con il comando show isdn status. Il telecomando deve indicare esplicitamente il tipo di switch da configurare. Occasionalmente (specialmente in Nord America) il telco può indicare che il tipo di commutatore è "personalizzato" o "nazionale". In questi casi, utilizzare le seguenti linee guida per determinare la configurazione dello switchtype:

  • Personalizzato: Se il messaggio telco indica che il tipo di switch è Custom, configurare il tipo di switch sul router come basic-5ess (per BRI con switch 5ess), primary-5ess (per PRI con 5ess), basic-dms (per BRI con switch DMS) o primary-dms (per PRI con DMS).

  • Nazionale: Tipo di switch conforme allo standard NI-1 per BRI e NI-2 per PRI (non esiste uno standard NI-1 per PRI). Se il messaggio telco informa che lo switch è di tipo nazionale, la configurazione del router Cisco deve essere di tipo Basic-In (per BRI) o primary-In (per PRI).

  Per configurare il tipo di switch, usare il comando isdn switch-type switch type in modalità di configurazione interfaccia BRI. Per un esempio, fare riferimento alla sezione Risoluzione dei problemi di ISDN BRI layer 1

• Verificare che i livelli ISDN 1 e 2 sul router chiamante funzionino:

  Per verificare che i livelli ISDN 1 e 2 siano attivi, usare il comando show isdn status. Per risolvere i problemi relativi al layer 1 e 2, usare la procedura descritta in Uso del comando show isdn status per la risoluzione dei problemi dei servizi BRI.

• Verificare che il numero di directory locale SPID (LDN) sia configurato correttamente

  Per alcuni tipi di commutatori, è necessario configurare correttamente lo spid e l'ldn in modo da accettare le chiamate in arrivo. Per ulteriori informazioni, fare riferimento a Risoluzione dei problemi degli SPID ISDN BRI.

Eseguire le attività seguenti sul router chiamante:

• Utilizzare un normale telefono analogico per effettuare una chiamata di prova al router remoto.

  Utilizzando un normale telefono analogico, comporre il numero ISDN del router chiamato esattamente come è configurato sul router chiamante. Il router chiamato dovrebbe ricevere un messaggio SETUP (anche se la chiamata non riuscirà in seguito poiché non è una chiamata ISDN). Se il router chiamato riceve il messaggio SETUP, si può supporre che la rete ISDN lato chiamato funzioni correttamente. Il problema potrebbe essere dovuto alla rete ISDN locale, al numero ISDN di destinazione, al servizio su lunghe distanze, ecc. Procedere come segue.

• Verificare che il numero ISDN di destinazione sia configurato correttamente:

  Controllare la configurazione del router chiamante e verificare che il numero ISDN configurato per il router remoto sia corretto. Molto spesso i circuiti ISDN dietro un PBX richiedono un 9 prima del numero ISDN. Inoltre, se la chiamata avviene a lunga distanza (negli Stati Uniti), è necessario includere la cifra 1 prima del numero ISDN del sito remoto (simile alla normale composizione telefonica a lunga distanza). Si consideri ad esempio una situazione in cui il sito locale è dietro un PBX e la chiamata al sito remoto deve essere una chiamata interurbana. Il numero ISDN dell'estremità remota è 5551111 all'interno dell'indicativo località 512. In questo caso, incluse le cifre appropriate per il PBX e la telefonia fissa, il numero composto è 915125551111.

  Il motivo di disconnessione debug isdn q931 può essere utilizzato anche per determinare se l'errore della chiamata è dovuto a un numero ISDN remoto errato o a un numero formattato in modo errato. Per ulteriori informazioni sull'interpretazione dei codici causa di disconnessione ISDN q931, consultare il documento Descrizione dei codici causa di disconnessione isdn di debug q931.

  Una disconnessione dovuta a un numero ISDN errato può essere indicata con:

  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
  

  Facendo riferimento al documento dei codici causa di disconnessione menzionato in precedenza, è possibile determinare che il codice di disconnessione è stato causato da un tentativo di connessione a un'apparecchiatura non ISDN. ad esempio una linea analogica.

  Una disconnessione dovuta a un numero formattato in modo errato può essere indicata con:

  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)
  

  Facendo riferimento al documento Descrizione dei codici causa di disconnessione isdn q931 di debug, è possibile stabilire che il codice di disconnessione è stato causato da un formato non valido per il numero ISDN remoto. La connessione non riesce perché l'indirizzo di destinazione è presentato (allo switch) in un formato non riconoscibile oppure l'indirizzo di destinazione è incompleto.

• Se applicabile, determinare se il servizio di assistenza a lunga distanza è attivo:

  Per verificare che il servizio sia attivato, contattare il provider di telecomunicazioni e interurbane locale. Spesso, la rete telefonica locale ha un circuito ISDN non configurato correttamente in modo che le chiamate ISDN in uscita su lunghe distanze non vengano commutate sulla rete del provider di servizi su lunga distanza appropriato. È inoltre consigliabile verificare che la rete di provider di servizi a lunga distanza sia funzionante.

  Negli Stati Uniti e nei casi in cui il fornitore di servizi di telecomunicazione o a lunga distanza non è in grado di risolvere il problema, è possibile utilizzare un vettore interscambio presottoscritto (PIC). I codici PIC sono prefissi a 7 cifre che identificano i vettori statunitensi di lunga distanza con i vettori locali (LEC). Ciò consente ai clienti di utilizzare diversi vettori per chiamate interurbane per chiamate separate. Il codice PIC è configurato come prefisso del numero composto. La maggior parte dei file PIC sono nel formato 1010xxx. Per un elenco numerico dei PIC, fare riferimento ai codici PIC statunitensi, numericamente

• Configurare due istruzioni dialer map o due istruzioni dialer string; uno per il numero ISDN di ciascun canale B remoto:

  Configurando una mappa dialer (o una stringa dialer, se si utilizzano profili dialer) per ciascun canale B remoto, è possibile procedere alla connessione anche se il telefono non è in grado di passare dalla seconda chiamata al secondo canale B ISDN.

  Nota: questa soluzione è necessaria se solo un canale B accetta chiamate su un determinato BRI. Questo problema si verifica spesso con le connessioni multiple.

  Viene fornita una configurazione di esempio (utilizzando le mappe dialer):

  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. 
  
  

Il router chiamato non invia un messaggio CONNECT

Se il router chiamato riceve un messaggio SETUP ma non risponde con un messaggio CONNECT, è possibile che il router (per qualche motivo indeterminato) scelga di non accettare la chiamata.

Eseguire le attività seguenti sul router chiamato:

• Verificare se la chiamata è stata rifiutata a causa dello screening basato su ID chiamante/DNIS:

  Lo screening basato sull'ID chiamante o sul DNIS consente al router di accettare o negare selettivamente una determinata chiamata senza incorrere in costi aggiuntivi. Con lo screening basato sull'ID chiamante, il router chiamato riceve (nel messaggio SETUP) il numero della parte chiamante. In questo modo, il router può consentire le chiamate da determinati numeri, garantendo una certa sicurezza. Con lo screening basato su DNIS, il router chiamato discrimina le chiamate in arrivo in base al numero composto.

  Per quanto riguarda lo screening basato su CLID/DNIS, è opportuno ricordare alcuni punti principali:

  1) Il telecom deve fornire le informazioni CLID/DNIS appropriate nel messaggio SETUP. Se si abilita lo screening dell'ID chiamante sul router, ma non si dispone delle cifre dell'ID chiamante passate al router, tutte le chiamate al router verranno "controllate" e non verrà accettata alcuna chiamata.

  2) Controllare il formato delle cifre CLID/DNIS fornite dal telecom (nell'output debug isdn q931). Ad esempio, alcune società di telecomunicazioni includono l'indicativo di località nelle cifre CLID/DNIS fornite, mentre altre no. Correggere le eventuali configurazioni CLID/DNIS.

  Di seguito è riportato un esempio di chiamata non riuscita. Tuttavia, sul router è abilitato lo screening basato su CLID, in quanto il telefono non consegna le cifre CLID e il router rifiuta la chiamata.

  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
  
  

  Per ulteriori informazioni sull'ID chiamante, consultare il documento relativo all'autenticazione ISDN e alla richiamata con ID chiamante

• Verificare che gli SPID siano corretti:

  Per verificare che gli SPID sul router chiamato siano corretti, usare il comando show isdn status. Per ulteriori informazioni sulla risoluzione dei problemi relativi allo Spid, fare riferimento a Uso del comando show isdn status per la risoluzione dei problemi BRI.

• Verificare che sul circuito composto siano presenti i canali B disponibili:

  Usare il comando show isdn status per verificare se sul circuito composto sono presenti canali disponibili. Se non sono disponibili canali, utilizzare il comando clear per liberare alcuni canali.

• Se sono disponibili più BRI, chiedere al telco di configurarli in un gruppo di risposta:

  La presenza di più BRI in un gruppo di risposta consente al telefono di commutare la chiamata a qualsiasi circuito BRI libero su quel router. Contattare la società di telecomunicazioni per questa funzione.

• Verificare se si stanno verificando problemi relativi alle funzionalità del supporto:

  La capacità del portante (o cappuccio portante) è l'indicazione di servizio di livello 3 che definisce le caratteristiche di una determinata chiamata. Il Bearer Cap di una chiamata è indicato dal telco nei messaggi Q.931 SETUP. Il cappuccio Bearer è spesso usato per distinguere tra chiamate vocali a 64k (analogiche), chiamate dati a 56k e chiamate dati a 64k. Di seguito sono riportati i messaggi più comuni e le relative descrizioni:

  Coperchio del supporto	Descrizione
  0x8890	Chiamata ISDN 64K
  0x8890218F	Chiamata ISDN 56K
  0x8090A2	Chiamata vocale (u-law)
  0x9090A2	Chiamata vocale/vocale (u-law) - 3,1 kHz audio
  0x8090A3	Chiamata vocale (A-law)
  0x9090A3	Chiamata vocale/vocale (A-law) - 3,1 kHz audio

  Di seguito è riportato un esempio di chiamata 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......
  

  Attenersi alla procedura seguente in base al berretto della chiamata:

  La capacità del supporto è 0x8890218F: La chiamata è in formato digitale ISDN 56K:

  • Verificare che il tipo di switch ISDN sia configurato correttamente:

    Il tipo di switch ISDN può essere verificato con il comando show isdn status. Il telecomando deve indicare esplicitamente il tipo di switch da configurare. Occasionalmente (specialmente in Nord America) il telco può indicare che il tipo di commutatore è "personalizzato" o "nazionale". In questi casi, utilizzare le seguenti linee guida per determinare la configurazione dello switchtype:

    • Personalizzato: Se il messaggio telco indica che il tipo di switch è Custom, configurare il tipo di switch sul router come basic-5ess (per BRI con switch 5ess), primary-5ess (per PRI con 5ess), basic-dms (per BRI con switch DMS) o primary-dms (per PRI con DMS).

    • Nazionale: Tipo di switch conforme allo standard NI-1 per BRI e NI-2 per PRI (non esiste uno standard NI-1 per PRI). Se il messaggio telco informa che lo switch è di tipo nazionale, la configurazione del router Cisco deve essere di tipo Basic-In (per BRI) o primary-In (per PRI).

    Per configurare il tipo di switch, usare il comando isdn switch-type switch type in modalità di configurazione interfaccia BRI. Per un esempio, fare riferimento alla sezione Risoluzione dei problemi di ISDN BRI layer 1

  • Dal lato della composizione, verificare che la velocità/velocità della chiamata sia 56k. Questa operazione è necessaria perché alcuni switch ISDN legacy potrebbero non passare il canale libero e potrebbe costringere l'utente a effettuare la chiamata a 56K per passare.

    Utilizzare il parametro speed nel comando di configurazione dialer map per effettuare chiamate in uscita a 56 Kbps, come mostrato nell'esempio seguente:

    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
    
    

    Nell'esempio seguente viene mostrato come configurare un profilo di connessione telefonica Cisco IOS per effettuare chiamate in uscita a 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)
    
    

  • Sul lato ricevente, configurare il comando isdn non-end-to-end 56 nell'interfaccia BRI.

    Maui-NAS-08(config)#interface bri 2/0
    Maui-NAS-08(config-if)#isdn not-end-to-end 56
    

    La funzionalità bearer Q.931 ISDN e altri elementi informativi (IE) vengono utilizzati per determinare la velocità della chiamata in arrivo e, nella maggior parte dei casi, funzionano correttamente. Tuttavia, in alcune applicazioni country-to-country (o a causa di alcuni switch legacy), il messaggio di configurazione della chiamata in arrivo verrà recapitato con una funzionalità al portatore che non corrisponde alla chiamata di origine. Se viene ricevuto un messaggio che indica che il protocollo isdn non è end-to-end, il router può ignorare la funzionalità di connessione ricevuta usando il comando di configurazione isdn non end-to-end di Cisco IOS.

    La capacità del supporto è 0x8090A2 o 0x9090A2: Chiamata vocale (u-law)

    La capacità del supporto è 0x8090A3 o 0x9090A3: Chiamata vocale (A-law)

    La chiamata in arrivo è una chiamata analogica a 64.000 rpm. Per le applicazioni modem, la chiamata verrà inviata ai modem interni, mentre per le applicazioni voce la chiamata potrà essere inviata al modulo vocale appropriato. Attenersi alla procedura seguente:

    1. Sul lato ricevente, verificare che l'interfaccia fisica ISDN (ad esempio, interfaccia bri 0) abbia un modem voce in ingresso isdn configurato.

    2. Verificare che le linee del modem abbiano il comando modem in out.

    Per un esempio di configurazione, consultare il documento sulla configurazione della connettività del modem con un Cisco 3640 BRI

  • Interpretare il codice della causa di disconnessione inviato (dal router chiamato al router chiamante) nel messaggio DISCONNECT o RELEASE

    Se il router chiamato non invia un messaggio CONNECT al router chiamante, deve inviare un messaggio DISCONNECT o RELEASE. Questo messaggio DISCONNECT o RELEASE deve includere anche un codice causa di disconnessione. Nell'esempio seguente, il codice causa di disconnessione è 0x8090. Per interpretare il codice causa di disconnessione, consultare il documento Descrizione dei codici causa di disconnessione isdn q931 di debug.

    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
    

Il router chiamante non riceve un messaggio CONNECT

Se il router chiamato invia un messaggio CONNECT ma il messaggio non viene ricevuto dal router chiamante, il problema più probabile è causato dal telefono.

• Determinare se il router riceve un comando CONNECT_ACK dallo switch ISDN locale:

  Ciò indica che lo switch telco vicino al router chiamato ha accettato il messaggio CONNECT e sta passando il messaggio CONNECT al router chiamante. Il guasto della chiamata è probabilmente un problema di telco.

• Per ulteriori informazioni sulla risoluzione dei problemi, contattare il supporto tecnico.

Il router chiamante riceve un comando CONNECT ma la chiamata non riesce

Se il router chiamante riceve un messaggio CONNECT, indica che la connessione ISDN è attiva e che funziona correttamente. Contattare la telco per determinare se si è verificato un problema con il canale B che non è stato mappato correttamente per i dati. Qualsiasi errore della chiamata, oltre questa fase, è dovuto a un problema di livello superiore, ad esempio con PPP, Autenticazione o Negoziazione di indirizzi IPCP/IP. Utilizzare la negoziazione ppp di debug per ulteriori operazioni di risoluzione dei problemi ppp.

È inoltre necessario consultare il documento Tecnologia di accesso remoto: Tecniche di risoluzione dei problemi per ulteriori tecniche di risoluzione dei problemi PPP.

Informazioni correlate

• Pagina di supporto sulle tecnologie Access
• Supporto tecnico – Cisco Systems

Cronologia delle revisioni