Bij problemen met oproepen door ISDN-probleemoplossing is het belangrijk om in gedachten te houden dat de oproep mislukt is door een van de volgende oorzaken:
Dial-on-demand routing (DDR)
ISDN-lagen 1, 2 en 3
Point-to-Point Protocol (PPP): inclusief LCP-problemen (Link Control Protocol), verificatie of IP-Control Protocol (IPCP).
Dit document concentreert zich specifiek op ISDN-gerelateerde kwesties die oproepfouten veroorzaken. Dit document gaat er ook van uit dat u hebt geverifieerd dat de lagen 1 en 2 van ISDN aan beide uiteinden van het circuit actief zijn. Raadpleeg het Opdracht ISDN-status voor BRI probleemoplossing gebruiken voor meer informatie over het controleren van ISDN Layer 1 en 2-status.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.
Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.
Gebruik de opdracht debug isdn q931 op beide uiteinden om ISDN Layer 3-apparaten te activeren. U zou ook milliseconde timestamps voor debugs op beide routers moeten hebben ingeschakeld. De tijdstempels zijn nodig om relatieve input te leveren voor het proces voor het oplossen van problemen.
Opmerking: activeert milliseconde tijdstampen voor debugs met de volgende opdrachten:
maui-soho-01(config)#service timestamps debug datetime msec maui-soho-01(config)#service timestamps log datetime msec
Raadpleeg voor meer informatie over debug-opdrachten belangrijke informatie over debug Commands.
Generate een ICMP aan het verre IP adres van de router. Dit zou een ISDN vraag naar die router moeten in werking stellen. Beide routers zullen debug-berichten van ISDN Q931 genereren.
De Q.931-beurzen kunnen veel variaties vertonen ten gevolge van specifieke eisen voor ISDN-switches of in gevallen waarin extra parameters vereist zijn. In het volgende schema wordt de gebruikelijke Q.931-transacties tijdens een succesvolle ISDN-aanroep weergegeven.
N.B.: Sommige van de volgende debug uitvoer worden voor afdrukken in meerdere regels verdeeld.
Calling Router | Gerelateerde router |
---|---|
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 |
Wanneer het evalueren van het debug-uitvoer van ISDN Q931 op het aanroepen en aanroepen van eindpunten, houd dan de volgende punten in gedachten:
Let op de richting van de berichten. Deze cijfers geven aan of de berichten door de router zijn gegenereerd (aangegeven door TX ->) of of of ze door de router zijn ontvangen (aangegeven door RX <—). In het onderstaande voorbeeld wordt het eerste bericht (CONNECT) door de router ontvangen vanuit de ISDN-Switch, terwijl het tweede (CONNECT_ACK) door de router wordt verzonden:
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
U kunt de bron van het probleem identificeren door de richting van een bepaald bericht en de reactie te volgen. Als de router bijvoorbeeld onverwachts een RELEASE-bericht uit de telco ISDN-switch ontvangt, wordt het einde van de verbinding ook hersteld. Dit wijst erop dat het probleem bij de telco ISDN-switch of de afstandsrouter ligt
Controleer of het ontvangen of verzonden bericht het verwachte is. Als de opgeroepen partij bijvoorbeeld een SETUP-bericht ontvangt maar een DISCONNECT versturen in plaats van een CONNECT, dan geeft u de opgeroepen router en niet het ISDN-netwerk een oplossing. In de volgende tabel is een lijst opgenomen van mogelijke Q.931-berichten die tijdens de belleninstelling en de verwijdering zijn waargenomen:
Bericht | Beschrijving |
---|---|
INSTELLEN | Instellen — Duidt erop dat een apparaat een Layer 3-aanroep wilt instellen |
BEL_PROC | Oproeproutering — De Oproeproutering is ontvangen en wordt verwerkt door het netwerk en/of het externe apparaat |
WAARSCHUWING | Alerting — stelt het netwerk in dat de eindrouter de gebruiker nu "waarschuwt"; dit zou normaal het geval zijn voor een telefoon en de waarschuwing zou de " ring " op de telefoon zijn . Dit bericht wordt normaal geassocieerd met apparatuur die een handset gebruikt, zoals een ISDN-telefoon of een TA en wordt gewoonlijk niet gezien voor gegevensoproepen. |
VERBINDEN | Connect — Bel wordt geaccepteerd |
CONNECT_ACK | Connect-kennis — Het apparaat heeft het CONNECT-bericht ontvangen. De hogere laagprotocollen (bijvoorbeeld. PPP) moet nu met de onderhandeling beginnen |
ONTKOPPELEN | Koppelen — door router geïnitieerde verbroken bericht. Dit bericht geeft doorgaans aan dat het ISDN-circuit werkt en dat de verbinding het gevolg was van een aantal problemen met een hogere laag (DDR, PPP enzovoort). De 3-way Disconnect Handshake zal vergezeld gaan van RELEASE en RELEASE_COMP berichten. Het DISCONNECT-bericht wordt ook vergezeld van een oorzaakcode voor verbroken verbinding. Deze scheidingscode kan worden gebruikt om aan te geven waar de verbinding van de verbinding was verbroken (de verbinding was bijvoorbeeld losgekoppeld van de router, lokale telco-switch, telco-switch op afstand enzovoort). Raadpleeg voor meer informatie het begrip "debug" van ISDN Q931 Oorzaak van verbroken verbinding |
UITSCHAKELEN | Release — Hiermee wordt de verbroken verbinding erkend en wordt de stroomuitval voortgezet. Het RELEASE-bericht is verdeeld tussen de DISCONNECT- en RELEASE_COMP-berichten. Het RELEASE-bericht kan vergezeld gaan van een oorzaakcode voor verbroken verbinding. Deze scheidingscode kan ook worden gebruikt om aan te geven waar de verbinding van de verbinding was verbroken (de verbinding was bijvoorbeeld losgekoppeld van de router, lokale telco-switch, telco-switch op afstand). Raadpleeg voor meer informatie het begrip debug van ISDN Q931 Oorzaakcodes van verbroken verbinding |
RELEASE-COMP | Complete — de verwijdering van de oproep is voltooid. Dit bericht wordt vaak gezien: a) Tijdens een normale gespreksbeëindiging die door een van de routers wordt geïnitieerd b) in reactie op een SETUP-bericht van de telefoonrouter. Dit wordt vaak veroorzaakt door een slechte verhouding van het vermogen aan toonder tussen de switch en de router. Een RELEASE_COMP kan ook worden veroorzaakt door protocolfouten als de codering van het SETUP-bericht niet voldoet aan de Q.931-standaard of de configuratie van de switch. Het RELEASE_COMP-bericht kan vergezeld gaan van een desconnect oorzaakcode. Deze scheidingscode kan ook worden gebruikt om aan te geven waar de verbinding van de verbinding was verbroken (de verbinding was bijvoorbeeld losgekoppeld van de router, lokale telco-switch, telco-switch op afstand). Raadpleeg voor meer informatie het begrip debug van ISDN Q931 Oorzaak van verbroken verbinding |
Analyse van de debug-uitvoer van ISDN Q931 zoals beschreven in de voorgaande secties, en ga verder naar de gewenste symptoom die hieronder wordt besproken.
Opmerking: In dit document wordt de router die de aanroep initieert ook aangeduid als de Calling Router, terwijl de router die de aanroep accepteert wordt aangeduid als de opgeroepen router.
Als de oprolrouter geen SETUP-bericht naar het ISDN-netwerk stuurt, is het probleem waarschijnlijk gerelateerd aan ISDN-lagen 1, 2 of Dial-on-Demand Routing (DDR) en is het niet op Layer 3 gerelateerd.
Voer de volgende taken uit op de telefoonrouter:
Controleer dat de ISDN-switchtypen correct zijn geconfigureerd:
Het ISDN-switchtypen kan worden geverifieerd met behulp van de ISDN-status van de opdrachtshow. De telco zou expliciet het switchtype moeten aangeven dat moet worden geconfigureerd. Zo nu en dan (vooral in Noord-Amerika) kan de telco aangeven dat de schakelaar "op maat" of "nationaal" is. Gebruik in dergelijke gevallen de volgende richtlijnen om de configuratie van het switchtype te bepalen:
Aangepast: Als het telco aangeeft dat hun switch-type Aangepast is, moet u de switchtype op de router configureren als basis-5ess (voor BRI met 5ess switch), primair-5ess (voor PRI met 5ess), basis-dms (voor BRI met DMS switch) of primaire-dms (voor PRI met DMS).
Nationaal: Het switchtype dat in overeenstemming is met de NI-1-norm voor BRI en NI-2-norm voor PRI (er is geen NI-1-norm voor PRI’s). Als het telco u informeert dat het switchtype Nationaal is, dan zou de Cisco routerconfiguratie basaal-in (voor BRI) of primair-in (voor PRI) moeten zijn.
Gebruik de opdracht ISDN switch-type switch-type in de BRI-interfacemodus om het type te configureren. Zie bijvoorbeeld Problemen oplossen door ISDN BRI Layer 1
Controleer dat de ISDN-lagen 1 en 2 op de bellenrouter werken:
U kunt verifiëren dat ISDN Lagen 1 en 2 omhoog zijn met de opdracht ISDN-status tonen. Gebruik de procedure die in is omlijnd om problemen bij ISDN Layer 1 en 2 op te lossen.
Gebruik de opdracht IP-route tonen om te controleren of de router een route naar de bestemming heeft.
De opdracht IP-route geeft aan of er een route naar het externe routernetwerk is. Als de route niet bestaat, gebruik de ip route opdracht om een statische route voor het externe netwerk toe te voegen. Zorg ervoor dat de routepunten in de juiste interface op de telefoonrouter zijn.
In een erfenis DDR-omgeving (bijvoorbeeld dialer maps) moet de volgende hop ofwel het fysieke interfacenetwerk (interface BRI x) of het externe router IP-adres zijn (dat ook in het dialer map statement zou moeten zijn geconfigureerd).
Met Kiezerprofielen is de volgende hop meestal de interface-snelkiezer x die voor het dialoogvenster wordt gebruikt. Bijvoorbeeld:
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
In het bovenstaande voorbeeld merkt u op dat de standaardroute volgende hop interface-snelkiezer 1 is (de logische dialerinterface voor deze verbinding).
Controleer dat het interessante verkeer juist is geïdentificeerd.
De router controleert om te verifiëren dat een inkomend pakket interessant verkeer is alvorens de wijzerplaat te openen. Vandaar, kan de router niet bellen als het interessante verkeer niet correct gedefinieerd is, of als het dialer-list nummer (de interessante verkeersdefinitie) niet van toepassing is op de fysieke of dialer interface (het dialer-group nummer opdracht gebruiken). Als u bijvoorbeeld een ICMP-ping gebruikt om de DDR-verbinding te openen, controleer dan of ICMP is toegestaan in de interessante verkeersdefinitie.
Raadpleeg het gedeelte BRI-to-BRI bellen met DDR Dialer-kaarten voor meer informatie.
Controleer of de juiste dialerstring (of dialerkaart) het ISDN-nummer van het afstandsapparaat bevat.
Het dialerstring (of dialerkaart) moet het ISDN-nummer van de router bevatten. Bijvoorbeeld:
dialer string 5551111 or dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
Controleer de DDR configuratie en gebruik debug dialer om te verifiëren dat de router de vraag in werking stelt:
Controleer dat de DDR configuratie juist is. Gebruik het document Dialup Technology: Overzichten en verklaringen voor verdere assistentie bij de juiste DDR-configuratie.
U zou ook het bevel moeten gebruiken debug dialer om te verifiëren dat de router interessant verkeer ontvangt en de aangewezen dialer kaart of dialer string heeft om de wijzerplaat te openen. Raadpleeg zowel het document als de inbeltechnologie: Technieken voor probleemoplossing voor meer informatie.
Raadpleeg de volgende voorbeeldconfiguratie voor voorbeelden van een juiste DDR-configuratie:
Kiezerprofielen: ISDN DDR configureren met Verouderde snelkiezerprofielen (snelkiezertoewijzingen): BRI-to-BRI bellen met DDR Dialer-kaarten configureren
Tip: Voor testdoeleinden kunt u DDR elimineren door de ISDN-gespreksopdracht te gebruiken (zoals uitgelegd in de volgende sectie) om een ISDN-oproep naar het externe apparaat te genereren. Als die oproep slaagt, kunt u redelijk zeker zijn dat het ISDN-circuit werkt. Doorgaan met oplossen van DDR
Voer een loopback testaanroep uit
In een loopback vraag, wijst de router het aantal van ISDN van zijn eigen BRI terug. De oproep gaat naar de telco-cloud, waar de telco de oproep naar het tweede BRI-kanaal switch. Deze vraag wordt nu door de router gezien als een inkomend gesprek op het tweede kanaal. Daarom wordt de router zowel verzonden als ontvangen door ISDN.
Een loopback vraag test de mogelijkheid van de router om een ISDN-vraag te openen en te beëindigen. Een succesvolle loopback vraag geeft u een sterke aanwijzing dat het ISDN circuit naar de telco cloud correct werkt.
Het volgende is een geannoteerd voorbeeld van een succesvolle loopback call. De commando ISDN aanroep (geïntroduceerd in Cisco IOS® software 12.0(3)T) maakt uitgaande ISDN aanroepen mogelijk zonder de DDR vereisten zoals interessant verkeer en routes te vereisen. Deze opdracht kan alleen worden gebruikt voor het testen van het ISDN-circuit, en kan niet worden gebruikt om verkeer door te geven of als vervanging voor een geschikte DDR-configuratie. Met deze opdracht kunnen we controleren of het ISDN-circuit, en met name Layer 3, werkt.
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
Opmerkingen:
Tijdens de loopback vraag, presteert de router zoals zowel de geroepen router evenals de Stembelrouter (alhoewel op verschillende B-kanalen). Het is belangrijk dat u deze "dubbele rollen" bijhoudt bij het interpreteren van de debug-uitvoer van ISDN Q931. De router stuurt bijvoorbeeld een setup-bericht (TX -> SETUP) en ontvangt ook een bericht (RX <-SETUP). De verzonden SETUP moet worden gekoppeld aan de uitgaande oproep terwijl het ontvangen SETUP-bericht gekoppeld is aan de inkomende oproep.
In het bovenstaande voorbeeld, kozen we het nummer voor het eerste B-kanaal. Echter, de telco die erkende dat het eerste B-kanaal bezig was (aangezien het de oproep deed), schakelde de oproep naar het tweede B-kanaal en de verbinding werd voltooid. Een foutieve configuratie in de telco-switch kan echter resulteren in een mislukking van de loopback-call, omdat de switch probeert de call aan het eerste kanaal toe te wijzen (dat bezig is met het maken van de oproep). De telco zou dit probleem moeten corrigeren. Als een workround oplossing specificeert u echter het tweede B-kanaalnummer in de opdracht ISDN-aanroep.
Als de loopback-upoproep slaagt en de oproep naar het externe einde blijft mislukken, neemt u contact op met de telco voor verdere probleemoplossing met uw BRI-circuit.
Als u bepaalt dat de Bel router een bericht van ISDN Layer 3 SETUP stuurt, maar dat de opgeroepen router het niet ontvangt, dan kan het probleem met ISDN-lagen 1 en 2 op de opgeroepen router zijn of kan het een probleem zijn met de telco ISDN-cloud.
Voer de volgende taken uit op de opgeroepen router:
Controleer dat de ISDN-switchtypen correct zijn geconfigureerd:
Het ISDN-switchtypen kan worden geverifieerd met behulp van de ISDN-status van de opdrachtshow. De telco zou expliciet het switchtype moeten aangeven dat moet worden geconfigureerd. Zo nu en dan (vooral in Noord-Amerika) kan de telco aangeven dat de schakelaar "op maat" of "nationaal" is. Gebruik in dergelijke gevallen de volgende richtlijnen om de configuratie van het switchtype te bepalen:
Aangepast: Als het telco aangeeft dat hun switch-type Aangepast is, moet u de switchtype op de router configureren als basis-5ess (voor BRI met 5ess switch), primair-5ess (voor PRI met 5ess), basis-dms (voor BRI met DMS switch) of primaire-dms (voor PRI met DMS).
Nationaal: Het switchtype dat in overeenstemming is met de NI-1-norm voor BRI en NI-2-norm voor PRI (er is geen NI-1-norm voor PRI’s). Als het telco u informeert dat het switchtype Nationaal is, dan zou de Cisco routerconfiguratie basaal-in (voor BRI) of primair-in (voor PRI) moeten zijn.
Gebruik de opdracht ISDN switch-type switch in de BRI-interfacemodus om het type te configureren. Zie bijvoorbeeld Problemen oplossen door ISDN BRI Layer 1
Controleer dat de ISDN-lagen 1 en 2 op de bellenrouter werken:
U kunt verifiëren dat ISDN Lagen 1 en 2 omhoog zijn met de opdracht ISDN-status tonen. Gebruik de procedure die is geschetst in Gebruik van de ISDN-status opdracht voor BRI probleemoplossing voor ISDN Layer 1 en 2-gerelateerde problemen.
Controleer dat het SPID Local Directory Number (LDN) correct is ingesteld
Bepaalde opties vereisen dat de spid en ldn correct worden geconfigureerd om inkomende oproepen te accepteren. Raadpleeg ISDN BRI SPID’s voor probleemoplossing voor meer informatie.
Voer de volgende taken uit op de telefoonrouter:
Gebruik een regelmatige analoge telefoon om een testvraag naar de afstandsrouter te maken.
Gebruik een regelmatige analoge telefoon, kies het ISDN-nummer van de opgeroepen router precies zoals dit op de bellenrouter is ingesteld. De opgeroepen router zou een SETUP-bericht moeten ontvangen (hoewel de oproep later mislukt omdat het geen ISDN-oproep is). Als de opgeroepen router het SETUP-bericht ontvangt, kunnen we ervan uitgaan dat het netwerk aan de andere kant van ISDN functioneert. Het probleem kan zijn met het lokale ISDN-netwerk, het ISDN-nummer van de bestemming, de langeafstandsservice, enzovoort. Volg onderstaande stappen.
Zorg ervoor dat het doelnummer van ISDN correct is geconfigureerd:
Controleer de configuratie van de router van het bellen en controleer of het ISDN-nummer dat voor de afstandsrouter is ingesteld, juist is. Zeer vaak vereist ISDN-circuits achter een PBX-systeem een 9 vóór het ISDN-nummer. Als het gesprek over lange afstand gaat (in de Verenigde Staten), moet u het cijfer 1 vóór het ISDN-nummer van de afstandssite (vergelijkbaar met het normale lange-afstandsbediening) toevoegen. Denk bijvoorbeeld aan een situatie waarin de lokale site achter een PBX staat en de oproep naar de externe site moet een langeafstandsbediening zijn. Het ISDN-nummer op afstand is 5551111 binnen gebiedscode 512. In dit geval, inclusief de juiste cijfers voor de PBX-systemen en de lange afstand, wordt het nummer 91512555111 weergegeven.
De reden voor het afsluiten van ISDN Q931 kan ook worden gebruikt om te bepalen of de fout bij de oproep te wijten is aan een onjuist extern ISDN-nummer of aan een onjuist geformatteerd nummer. Raadpleeg het document Understanding om ISDN Q931 verbroken Oorzaakcodes te zuiveren voor meer informatie over het interpreteren van ISDN q931 waarin oorzaakcodes worden losgekoppeld.
Een verbroken verbinding vanwege een incorrect ISDN-nummer kan worden aangegeven met:
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
Verwijzing naar het eerder genoemde document van de oorzaakcodes van verbroken verbinding, kunnen we bepalen dat de code is ontstaan door een poging om verbinding te maken met een niet-ISDN-apparatuur. (Bijvoorbeeld een analoge lijn.)
Een verbroken verbinding door een niet juist geformatteerd nummer kan worden aangegeven met:
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)
Verwijs naar het document Understanding debug isdn Q931 Deconnect Oorzaakcodes, dan kunnen we bepalen dat de verbroken code werd veroorzaakt door een ongeldig formaat voor het externe ISDN-nummer. De verbinding mislukt, omdat het doeladres (aan de switch) in een niet-herkennbaar formaat wordt aangeboden of het doeladres onvolledig is.
Indien van toepassing, vaststellen of de langeafstandsdienst actief is:
U dient contact op te nemen met de lokale telco- en langeafstandsbediening om te controleren of de service is geactiveerd. Vaak heeft de lokale telco het ISDN-circuit verkeerd ingesteld, zodat de uitgaande ISDN-oproepen op lange afstand niet worden overgeschakeld op het juiste lange-afstand provider-netwerk. U dient ook te controleren of het langeafstandsdienstennetwerk functioneert.
In de VS en in situaties waarin de telco/langeafstandsaanbieder het probleem niet kan verhelpen, kunt u een PreSubscribed Interexchange Carrier (PIC) gebruiken. PIC-codes zijn prefixes met 7 cijfers die de Amerikaanse langeafstandsvervoerders naar de lokale uitwisselingsvervoerders (LEC) identificeren. Dit stelt klanten in staat om verschillende langeafstandsvervoerders te gebruiken voor afzonderlijke gesprekken. De PIC-code wordt ingesteld als voorvoegsel bij het geselecteerde nummer. De meeste PIC’s hebben het formaat 1010xxx. Voor een numerieke lijst van PIC's wordt verwezen naar Amerikaanse PIC-codes, numeriek
Configureer twee dialer-map of twee dialer-string-statements; één voor het ISDN-nummer van elk extern B-kanaal:
Het configureren van een dialerkaart (of een dialerstring, indien gebruikt van dialerprofielen) voor elk extern B-kanaal laat de verbinding toe om te verdergaan zelfs als het telco niet in staat is om de tweede aanroep naar het tweede ISDN B-kanaal over te schakelen.
Opmerking: Deze workround is vereist als slechts 1 B-kanaal aanroepen op een bepaalde BRI accepteert. Dit probleem wordt vaak gezien met multilink connecties.
Er wordt een voorbeeldconfiguratie geboden (met behulp van dialerkaarten):
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.
Als de opgeroepen router een SETUP-bericht ontvangt maar niet reageert met een CONNECT-bericht, dan kan dit erop wijzen dat de router (om een of andere onbepaalde reden) heeft besloten de oproep niet te accepteren.
Voer de volgende taken uit op de opgeroepen router:
Controleer of de oproep is verworpen vanwege een screening op basis van nummerherkenning/DNIS:
Een op Caller ID of DNIS gebaseerde screening maakt het de router mogelijk om een bepaalde oproep selectief te accepteren of te ontkennen zonder dat er tolkosten aan verbonden zijn. Met screening op basis van nummerherkenning ontvangt de opgeroepen router (in het SETUP-bericht) het nummer van de bellenpartij. Dit staat de router toe om vraag van bepaalde getallen toe te staan en voorzien in enige veiligheid. Met DNIS-gebaseerde screening discrimineert de opgeroepen router inkomende oproepen op basis van het geselecteerde nummer.
Er zijn een aantal belangrijke punten om te onthouden met betrekking tot op CLID/DNIS gebaseerde screening:
1) De telco moet de juiste CLID/DNIS-informatie in het SETUP-bericht verstrekken. Als u de screening van ID van de programma's op de router toestaat, maar geen cijfers van de nummerherkenning die aan de router worden doorgegeven zijn alle oproepen aan de router "vertoond" en geen oproepen zullen worden geaccepteerd.
2) Controleer het formaat van de CLID/DNIS-cijfers die door de telco zijn geleverd (in de debug ISDN q931-uitvoer). Sommige telcos bevatten bijvoorbeeld de gebiedscode in de geleverde CLID/DNIS-cijfers, terwijl andere niet. Corrigeer eventuele CLID/DNIS-configuratie indien nodig.
Het volgende is een voorbeeld van een mislukt gesprek. De router heeft op CLID gebaseerde screening ingeschakeld, echter, aangezien het telco de CLID-cijfers niet levert, wijst de router de oproep af.
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
Raadpleeg voor meer informatie over Nummerherkenning het document, de ISDN-verificatie en de terugbellen met de nummerherkenning
Controleer of de SPID's juist zijn:
Gebruik het bevel van de show isdn status om te verifiëren dat SPIDs op de geroepen router correct zijn. Raadpleeg Het gebruik van de ISDN-status Opdracht voor BRI probleemoplossing voor meer informatie over problemen met betrekking tot probleemoplossing bij het oplossen van problemen.
Zorg ervoor dat er B-kanalen beschikbaar zijn in het circuit dat is geselecteerd:
Gebruik de opdracht ISDN-status tonen om te controleren of er beschikbare kanalen in het circuit zijn die zijn geselecteerd. Als er geen beschikbare kanalen zijn, gebruikt u de duidelijke opdracht om bepaalde kanalen vrij te maken.
Als meerdere BRIs beschikbaar zijn, moet de telco hen in een jachtgroep configureren:
Het hebben van meerdere BRIs in een jachtgroep staat voor telco toe om de vraag aan om het even welk vrij BRI circuit op die router te switches. Neem contact op met de telco voor deze functie.
Controleer of u problemen ondervindt met betrekking tot uw vermogen:
De bijdraagbaarheid (of de dop aan toonder) is de dienstindicatie van laag 3 die de kenmerken van een bepaalde oproep definieert. Het maximum aan toonder van een oproep wordt door de telco aangegeven in de berichten van Q.931 SETUP. De dop aan toonder wordt vaak gebruikt om onderscheid te maken tussen 64k spraak (analoog), 56k gegevensaanroepen en 64k gegevensaanroepen. Hieronder worden de meest algemeen bekende berichten met betrekking tot toonder en hun beschrijvingen gegeven.
dop aan toonder | Beschrijving |
---|---|
0x890 | ISDN 640K-oproep |
0x890/218F | ISDN 560K-oproep |
0x8090A2 | Spraak/spraak (u-wet) |
0x9090A2-software | Voice/Speech-oproep (u-wet) - 3,1 kHz Audio |
0x8090A3-software | Spraak/spraak (A-wet) |
0x9090A3-software | Voice/Speech-oproep (A-wet) - 3,1 kHz Audio |
Het volgende is een voorbeeld van een ISDN 64k-oproep:
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......
Volg de onderstaande stappen, afhankelijk van de toonder van de oproep:
Toonder-capaciteit is 0x890218F: De verbinding is ISDN 56K digitaal:
Controleer dat de ISDN-switchtypen correct zijn geconfigureerd:
Het ISDN-switchtypen kan worden geverifieerd met behulp van de ISDN-status van de opdrachtshow. De telco zou expliciet het switchtype moeten aangeven dat moet worden geconfigureerd. Zo nu en dan (vooral in Noord-Amerika) kan de telco aangeven dat de schakelaar "op maat" of "nationaal" is. Gebruik in dergelijke gevallen de volgende richtlijnen om de configuratie van het switchtype te bepalen:
Aangepast: Als het telco aangeeft dat hun switch-type Aangepast is, moet u de switchtype op de router configureren als basis-5ess (voor BRI met 5ess switch), primair-5ess (voor PRI met 5ess), basis-dms (voor BRI met DMS switch) of primaire-dms (voor PRI met DMS).
Nationaal: Het switchtype dat in overeenstemming is met de NI-1-norm voor BRI en NI-2-norm voor PRI (er is geen NI-1-norm voor PRI’s). Als het telco u informeert dat het switchtype Nationaal is, dan zou de Cisco routerconfiguratie basaal-in (voor BRI) of primair-in (voor PRI) moeten zijn.
Gebruik de opdracht ISDN switch-type switch in de BRI-interfacemodus om het type te configureren. Zie bijvoorbeeld Problemen oplossen door ISDN BRI Layer 1
Controleer aan de kant van het draaien of de snelheid/het tarief van de oproep 56k is. Dit is nodig omdat bepaalde ISDN-switches mogelijk niet over een duidelijk kanaal beschikken en u mogelijk dwingen om uw oproep bij 56K te doen om er doorheen te komen.
Gebruik de snelheid parameter op het dialer map configuratie opdracht om uitgaande gesprekken op 56 Kbps aan te roepen zoals in het volgende voorbeeld wordt getoond:
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
Het volgende voorbeeld illustreert hoe te om een Cisco IOS dialerprofiel te vormen om uitgaande vraag op 56 Kbps te maken:
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)
Aan de ontvangende kant, moet u de opdracht niet-end-to-end 56 configureren onder de BRI-interface.
Maui-NAS-08(config)#interface bri 2/0 Maui-NAS-08(config-if)#isdn not-end-to-end 56
De gebruikersinterface van ISDN Q.931 en ander informatie-element (IE) worden gebruikt om de snelheid van de inkomende oproep te bepalen en zal in de meeste omstandigheden correct functioneren. In sommige land-aan-land toepassingen (of door een aantal switches van de erfenis) zal het inkomende bericht van de vraagopstelling echter worden geleverd met een dragercapaciteit die niet overeenkomt met de oorspronkelijke oproep. Als een bericht dat ISDN 'niet end-to-end' aangeeft, wordt ontvangen, kan de router de ontvangen toonder-mogelijkheid omzeilen met behulp van het Cisco IOS-configuratieopdracht is niet end-to-end.
Toonder-capaciteit is 0x8090A2 of 0x9090A2: Spraak/spraak (u-wet)
Toonder-capaciteit is 0x8090A3 of 0x9090A3: Spraak/spraak (A-wet)
Het inkomende gesprek is een 64k analoge vraag. Voor modemtoepassingen zal de vraag naar de interne modems worden verzonden, terwijl voor spraaktoepassingen de vraag naar de juiste spraakmodule kan worden verzonden. Volg de volgende stappen:
Aan de ontvangende kant, controleer of de fysieke interface van ISDN (bijvoorbeeld, interface bri 0) inkomend-spraak modem heeft geconfigureerd.
Controleer dat de modemlijnen de opdracht modeminformatie hebben.
Raadpleeg voor een voorbeeldconfiguratie het document Connectiviteit met modem en een Cisco 3640 BRI
Tolk de code van de verbindingsoorzaak die (van de geroepen router naar de Stellende router) in het ONGEBONDEN of RELEASE bericht wordt verzonden
Als de opgeroepen router geen CONNECT-bericht naar de bellenrouter stuurt, moet u een DISCONNECT- of RELEASE-bericht terugsturen. Dit DISCONNECT- of RELEASE-bericht moet ook een oorzaakcode van verbroken verbinding bevatten. In het onderstaande voorbeeld is de code van de Oorzaak van verbroken verbinding 0x8090. Raadpleeg het document dat de betekenis van het bestand debug van ISDN q931 van de verbroken Oorzaak interpreteert om de koppelingscode te interpreteren.
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
Als de opgeroepen router een CONNECT-bericht verstuurt, maar dat bericht niet wordt ontvangen door de opgeroepen router, ligt de probleem waarschijnlijk bij het telco.
Bepaal of de router CONNECT_ACK van de lokale switch van ISDN ontvangt:
Dit betekent dat de telco switch in de buurt van de opgeroepen router het CONNECT-bericht heeft geaccepteerd en het CONNECT-bericht naar de bellenrouter heeft verzonden. Een mislukking van de oproep is waarschijnlijk een telecomprobleem.
Neem contact op met de telco voor verdere probleemoplossing.
Als de Bel router een CONNECT-bericht ontvangt, geeft dat aan dat de ISDN-verbinding actief en correct functioneert. Neem contact op met de telco om te bepalen of er een probleem is met het B-kanaal dat niet correct in kaart is gebracht voor gegevens. Elke mislukking van de oproep, voorbij dit stadium, is veroorzaakt door een hoger laagprobleem zoals met PPP, Verificatie of IPCP/IP-adresonderhandeling. Gebruik debug ppp onderhandeling voor verdere problemen oplossen.
U dient ook het document Dialup Technology te raadplegen: Technieken voor probleemoplossing voor verdere PPP-technieken voor probleemoplossing.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
04-Feb-2010 |
Eerste vrijgave |