Cisco IOS Gatekeeper Call Routing

Einführung

Cisco Gatekeeper werden verwendet, um Gateways in logische Zonen zu gruppieren und die Anrufweiterleitung zwischen ihnen durchzuführen. Gateways sind für Edge-Routing-Entscheidungen zwischen dem Public Switched Telefone Network (PSTN) und dem H.323-Netzwerk verantwortlich. Cisco Gatekeeper übernehmen die zentrale Anrufweiterleitung zwischen Geräten im H.323-Netzwerk und ermöglichen die zentrale Verwaltung von Wählplänen. Ohne einen Cisco Gatekeeper müssen explizite IP-Adressen für jedes terminierende Gateway am ursprünglichen Gateway konfiguriert und einem Voice over IP (VoIP)-Dial-Peer zugeordnet werden. Mit einem Cisco Gatekeeper fragen Gateways beim Versuch, VoIP-Anrufe mit Remote-VoIP-Gateways herzustellen, den Gatekeeper ab.

Wenn beispielsweise ein Anruf angezeigt wird, bestimmt das Gateway, ob dieser gemäß dem Wählplan an den Telefoniestrang oder an den IP-Abschnitt gesendet werden soll. Im Fall der IP-Komponente fragt das Gateway den Cisco Gatekeeper ab, um den besten Endpunkt auszuwählen. Anschließend bestimmt der Cisco Gatekeeper, ob es sich bei dem angerufenen Endpunkt um ein Gerät innerhalb der lokalen Zone oder um ein Gerät in einer Remote-Zone handelt, die von einem entfernten Cisco Gatekeeper gesteuert wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse der H.323-Gatekeepers verfügen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Cisco Router der Serien 2500, 2600, 3600, 3700, 7200 und MC3810

• Dieses Dokument bezieht sich nicht auf eine beliebige Version von Cisco IOS®. Die Konfigurationen in diesem Dokument wurden jedoch mit Version 12.2(19) der Cisco IOS-Software getestet. Informationen zur Unterstützung der H.323-Gatekeeper-Funktion finden Sie im Software Advisor (nur registrierte Kunden).

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

ARQ- und LRQ-Nachrichten

Bei den beiden Nachrichten für die H.225-Registrierung, die Zulassung, den Status (RAS) und die Standortanforderung (LRQ) handelt es sich um die beiden Nachrichten für die H.225-Registrierung, die Aufnahme, den Status (RAS), die einen Gatekeeper zum Initiieren des Entscheidungsprozesses für die Anrufweiterleitung auslösen.

• ARQ: Nachrichten aus der lokalen Zone, die von H.323-Endpunkten (in der Regel Gateways) an den Cisco Gatekeeper gesendet werden. Gatekeepers erhalten ARQs von einem Endpunkt, wenn:

  • Ein Endpunkt der lokalen Zone initiiert einen Anruf. ODER

  • Ein Endpunkt der lokalen Zone fordert die Berechtigung zum Zulassen eines eingehenden Anrufs an.

  Gatekeepers antworten auf ARQ-Nachrichten mit einer ACF- (Admission Confirm) oder ARJ-Nachricht (Admission Reject). Wenn der Cisco Gatekeeper so konfiguriert ist, dass er den Anruf zugibt, antwortet er mit einer ACF-Nachricht (die Informationen wie die IP-Adresse des Ziel-Gateways enthält). Ist dies nicht der Fall, antwortet er mit einer ARJ-Nachricht.

• LRQ: Diese Nachrichten werden zwischen Gatekeepern ausgetauscht und für Anrufe zwischen Zonen (Remote-Zonen) verwendet. Gatekeeper A empfängt beispielsweise ein ARQ von einem Gateway der lokalen Zone, das den Anrufzugriff für ein Gerät der Remote-Zone anfordert. Gatekeeper A sendet dann eine LRQ-Nachricht an Gatekeeper B. "Gatekeeper B" antwortet auf die LRQ-Nachricht entweder mit einer LCF-Nachricht (Location Confirm) oder einer LRJ-Nachricht (Location Reject), die davon abhängt, ob sie für das Zugeben oder Ablehnen der Anrufanfrage zwischen den Zonen konfiguriert ist und ob die angeforderte Ressource registriert ist.

Informationen zu H.323-Gatekeepers finden Sie unter: Anrufablauf zwischen Gatekeeper für weitere Informationen.

Wichtige Konfigurationskonzepte: Zone und Technologie-Präfixe

Um den Entscheidungsprozess für die Anrufweiterleitung bei Cisco Gatekeeper zu verstehen, müssen Zone- und Technologie-Präfixe verstanden werden. Im Allgemeinen (mit einigen Ausnahmen) bestimmt das Zonenpräfix das Routing zu einer Zone, während das Technologiepräfix das Gateway in dieser Zone bestimmt.

Zonenpräfixe

Ein Zonenpräfix ist der Teil der angerufenen Nummer, der die Zone angibt, zu der ein Anruf aufhört. Zonenpräfixe werden normalerweise verwendet, um einer konfigurierten Zone einen Bereichscode zuzuordnen.

Der Cisco Gatekeeper bestimmt, ob ein Anruf an eine Remote-Zone weitergeleitet oder lokal bearbeitet wird. Beispielsweise leitet gatekeeper (GK) A nach diesem Konfigurationsauszug 214 weiter...... Anrufe an GK-B. Anrufe bei Ortsvorwahl (512) werden lokal verarbeitet.

gatekeeper
     zone local GK-A abc.com
     zone remote GK-B abc.com 172.22.2.3 1719
	
!--- The IP address configured above should be the RAS !--- address of the remote gatekeeper. !--- and should be reachable from the local gateway. !--- In order to find out the RAS address on the remote gatekeeper, !--- issue the  show gatekeeper zone status  command !--- on the remote gateway.
 
     zone prefix GK-B 214.......
     zone prefix GK-A 512.......

Technologie-Präfixe

Ein Technologiepräfix ist eine optionale standardbasierte H.323-Funktion, die von Cisco Gateways und Gatekeeper unterstützt wird und eine flexiblere Anrufweiterleitung innerhalb eines H.323 VoIP-Netzwerks ermöglicht. Der Cisco Gatekeeper verwendet technologische Präfixe, um Endpunkte desselben Typs zu gruppieren. Technologiepräfixe können auch verwendet werden, um einen Typ, eine Klasse oder einen Pool von Gateways zu identifizieren.

Cisco Gatekeeper verwenden Technologie-Präfixe, um Anrufe weiterzuleiten, wenn keine E.164-Adressen registriert sind (durch ein Gateway), die mit der angerufenen Nummer übereinstimmen. Dies ist ein gängiges Szenario, da die meisten Cisco IOS-Gateways nur ihre H.323-ID registrieren (es sei denn, sie verfügen über konfigurierte Foreign Exchange Station (FXS)-Ports). Ohne E.164-Adressen ist der Cisco Gatekeeper auf zwei Optionen angewiesen, um die Anrufweiterleitung zu entscheiden:

• Mit der Option Technologiepräfix-Übereinstimmungen wählt der Cisco Gatekeeper das an die angerufene Nummer angehängte Technologiepräfix für das Ziel-Gateway oder die Zielzone aus.

• Mit der Option "Default Technology Prefixes" (Standardtechnologiepräfixe) weist der Cisco Gatekeeper Standard-Gateways für das Routing nicht aufgelöster Anrufadressen zu. Diese Zuweisung basiert auf dem registrierten Technologiepräfix der Gateways.

In dieser Tabelle sind die verfügbaren Konfigurationsoptionen zusammengefasst:

GWY-B1(config)#interface ethernet 0/0
GWY-B1(config-if)#h323-gateway voip tech-prefix ?
     WORD: A technology prefix that the interface will register
     with the Gatekeeper.

GWY-B1(config)#dial-peer voice 2 voip
GWY-B1(config-dial-peer)#tech-prefix ?
     WORD: A string.

GK-B(config)#gatekeeper
GK-B(config-gk)#gw-type-prefix 1# default-technology

GK-B(config)#gatekeeper 
GK-B(config-gk)#gw-type-prefix 2# hopoff GK-A

GK-B(config)#gatekeeper 
GK-B(config-gk)#gw-type-prefix 1# gw ipaddr ?
     A.B.C.D  Gateway's call signaling IP address

Algorithmus/Entscheidungsprozess für die Anrufweiterleitung bei Gatekeeper

Diese Diagramme zeigen den Entscheidungsprozess für die Gateway-Anrufweiterleitung nach Erhalt von ARQ- und LRQ-Nachrichten in Cisco IOS Software Releases vor 12.4:

Alias-basierte Anrufweiterleitung

Die Gatekeeper-Anrufweiterleitung hat sich in Version 12.4 und höher der Cisco IOS-Software geändert. Die H.323-ID- und E-Mail-ID-basierte Zuordnung wird vor der Verarbeitung der E.164-Zielnummern (DNIS) durchgeführt. Wenn festgestellt wird, dass ein Endpunkt die angegebene H.323-ID/E-Mail-ID registriert hat, wird der ACF gesendet. In diesem Diagramm wird der neue Alias-basierte Anrufweiterleitungsprozess erläutert:

Die Voice Infrastructure and Application (VIA)-Funktionen sind Softwareerweiterungen des vorhandenen Cisco Gatekeeper-Images. Mit dieser Erweiterung kann der Cisco Gatekeeper zwei Anrufabschnitte auf derselben Plattform (IP-to-IP-Gateway) erkennen und außerdem den Datenverkehr über mehrere IP-to-IP-Gateways ausgleichen, die (sowohl Gateways als auch Gatekeeper) in einer vordefinierten VIA-Zone enthalten sind. Diese Gatekeeper befinden sich am Edge des ITSP-Netzwerks (Internet Telefony Service Provider) und sind wie ein VoIP-Übertragungspunkt oder eine Transit-Zone, in der der VoIP-Datenverkehr auf dem Weg zum Ziel der Remote-Zone weitergeleitet wird. IP-to-IP-Gateways in der VIA-Zone terminieren eingehende Anrufe und leiten sie an ihre endgültigen Ziele zurück. Weitere Informationen zur VIA-Zone finden Sie unter Remote to Local Network with the Cisco Multiservice IP-to-IP Gateway Feature (Remote zu lokalem Netzwerk mit der Funktion für IP-to-IP-Multiservice).

Hinweis: Wenn die angegebene In- oder Outvia-Zone nicht in den Konfigurationen gefunden wird (d. h. nicht als lokale oder Remote-Zone definiert ist), wird eine ARJ-Nachricht gesendet.

Zur Auswahl eines für den ausgewählten Viazon registrierten IP-IP-GW wird folgender Algorithmus verwendet:

1. Wenn ein technisches Präfix gefunden wird (in Alias-basierter Übereinstimmung), sehen Sie sich die Liste der Gateways in dem angegebenen Viazon an, die dieses technische Präfix registriert haben.

2. Wenn kein technisches Präfix gefunden wird, sehen Sie sich die gesamte Liste der Gateways an, die für das angegebene Viazon registriert sind.

3. Wählen Sie den ersten in Schritt 1 oder 2 gefundenen IP-IP-GW aus, der über verfügbare Ressourcen verfügt.

4. Wenn alle IP-IP-GWs in der Liste nicht über genügend Ressourcen verfügen, wählen Sie das erste IP-IP-GW aus, das gefunden wird (obwohl es möglicherweise nicht über genügend Ressourcen verfügt).

5. Wenn keine IP-IP-GWs gefunden werden, wird ein Fehler zurückgegeben.

Beispiele für Anrufe in der lokalen Zone

In den Beispielen in diesem Abschnitt registrieren sich die beiden Gateways beim Cisco Gatekeeper mit ihren jeweiligen H.323-IDs. Darüber hinaus registriert Gateway A2 eine E.164-Adresse. Dieses Diagramm wird für alle Beispiele in diesem Abschnitt verwendet:

In den drei Szenarien in diesem Abschnitt wird der schrittweise Entscheidungsprozess erläutert, den der Gatekeeper zum Weiterleiten von Anrufen basierend auf den ARQ-Nachrichten verwendet.

Hinweis: In diesen Konfigurationserfassungen werden nur relevante Ergebnisse angezeigt.

Szenario 1: Keine technologischen Präfixe konfiguriert

!
gatekeeper
zone local GK-A abc.com
no shutdown
!

!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718 
 !--- The IP address configured here should !--- be the RAS address of GK-A !--- and should be reachable from the gateway. !--- In order to find out the RAS address, !--- issue the  show gatekeeper zone status  !--- command on GK-A.
 
h323-gateway voip h323-id GW-A1@abc.com 
!
dial-peer voice 1 pots
destination-pattern 512.......
direct-inward-dial
port 1/0:23
prefix 512

!--- On outgoing calls through POTS dial-peers, !--- all explicit digit matches are dropped, !--- which is the reason !--- for adding the prefix 512. This has nothing to !--- do with technology prefixes.

!
dial-peer voice 2 voip
destination-pattern 972.......
session target ras

!--- Uses RAS messages (GK) to get !--- call setup information.


!
gateway
!

!
interface FastEthernet0/0
ip address 172.22.1.2 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718

!--- The IP address configured here !--- should be the RAS address of GK-A. !--- and should be reachable from the gateway. !--- In order to find out the RAS address, !--- issue the  show gatekeeper zone status  !--- command on GK-A.
 
h323-gateway voip h323-id GW-A2@abc.com
!
dial-peer voice 1 voip
destination-pattern 512.......
session target ras
!
dial-peer voice 2 pots
destination-pattern 9725551010
port 1/0/0

!--- This is the FXS port.

!
gateway
!

Diese auf GK-A erfasste Ausgabe zeigt die eigentlichen Registrierungen an. Beachten Sie, dass GWY-A2 auch die E.164-ID des FXS-Ports registriert.

GK-A#show gatekeeper endpoints
                    GATEKEEPER ENDPOINT REGISTRATION
                    ================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type    F
--------------- ----- --------------- ----- ---------         ----    --
172.22.1.1      1720  172.22.1.1      49317 GK-A              VOIP-GW
    H323-ID: GW-A1@abc.com
172.22.1.2      1720  172.22.1.2      58196 GK-A              VOIP-GW
    E164-ID: 9725551010
    H323-ID: GW-A2@abc.com
Total number of active registrations = 2

Erste Anrufaktion: Benutzer A1 ruft Benutzer A2 unter der Nummer 972-555-1010 an. Verwenden Sie das ARQ-Diagramm, um den Entscheidungsprozess abzuschließen.

GK-A empfängt ARQ von GWY-A1.

1. Stimmt das Technologiepräfix überein? Nein

2. Stimmt das Zonenpräfix überein? Nein

3. Ist der Befehlssatz arq reject-known-prefix festgelegt? Nein, die Zielzone entspricht der lokalen Zone.

4. Ist die Zielzone lokal? Ja

5. Wurde in Schritt 1 ein Technologiepräfix gefunden? Nein

6. Ist die Zieladresse registriert? Ja. Senden Sie ACF.

Einrichtung des Anrufs erfolgreich.

Hinweis: GWY-A2 hat die Ziel-E.164-ID registriert (FXS-Port). Daher konnte der Gatekeeper den Anruf zugeben.

Zweite Anrufaktion: Benutzer A2 wählt 512-555-1212, um Benutzer A1 anzurufen.

GK-A empfängt ARQ von GWY-A2.

1. Stimmt das Technologiepräfix überein? Nein

2. Stimmt das Zonenpräfix überein? Nein

3. Ist der Befehlssatz arq reject-known-prefix festgelegt? Nein, die Zielzone entspricht der lokalen Zone.

4. Ist die Zielzone lokal? Ja

5. Wurde in Schritt 1 ein Technologiepräfix gefunden? Nein

6. Ist die Zieladresse registriert? Nein

7. Ist das technische Standardpräfix festgelegt? Nein. Senden Sie ARJ.

Einrichtung des Anrufs fehlgeschlagen.

Hinweis: Szenario 2 erläutert, wie dieses Problem bei der Anrufweiterleitung mithilfe von Technologiepräfixen behoben wird.

Szenario 2: Konfigurierte Technologie-Präfixe

In diesem Szenario werden folgende Konfigurationsänderungen vorgenommen:

• GWY-A1: Der Befehl h323-gateway voip tech-prefix 1# wurde hinzugefügt. GWY-A1 wird mit dem Technologiepräfix 1# beim GK-A registriert.

• GWY-A1: Es wurde ein POTS-Dial-Peer mit einem Ziel-Muster-Befehl hinzugefügt, der der eingehenden angerufenen Nummer von GWY-A2 mit dem Technologiepräfix 1# entspricht.

• GK-A: Zonenpräfix GK-A-Befehl hinzugefügt. Definiert die Präfixe der lokalen Zone, die von GK-A verwaltet werden.

• GK-A: Der Befehl arq reject-known-prefix wurde hinzugefügt. Dadurch wird GK-A gezwungen, nur ARQ-Anrufe für die von ihm verwalteten Zonenpräfixe zu akzeptieren. In Szenario 1 wurde dies nicht konfiguriert. Aus diesem Grund wurde die Zielzone als Standard auf die lokale Zone festgelegt.

• GWY-A2: Der Befehl tech-prefix 1# unter der VoIP-DFÜ-Peer-Konfiguration wurde hinzugefügt. Auf diese Weise stellt GWY-A2 den ausgehenden VoIP-Anrufen die Ziffern 1# voraus. GK-A identifiziert das 1#-Muster, um GWY-A1 als Ziel-Gateway auszuwählen.

gatekeeper
zone local GK-A abc.com
zone prefix GK-A 512.......
zone prefix GK-A 972.......
arq reject-unknown-prefix
no shutdown
!

!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A1@abc.com
h323-gateway voip tech-prefix 1# 
!
dial-peer voice 3 pots
incoming called-number 972.......
destination-pattern 1#512.......
direct-inward-dial
port 1/0:23
prefix 512
!
dial-peer voice 2 voip
destination-pattern 972.......
session target ras
!
gateway
!

!
dial-peer voice 1 voip
destination-pattern 512.......
session target ras
tech-prefix 1#
!
dial-peer voice 2 pots
destination-pattern 9725551010
port 1/0/0
!
gateway
!
interface FastEthernet0/0
ip address 172.22.1.2 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A2@abc.com
!

Diese auf GK-A erfasste Ausgabe zeigt die registrierten Technologiepräfixe an:

GK-A#show gatekeeper gw-type-prefix
        
        GATEWAY TYPE PREFIX TABLE
        =========================
        Prefix: 1#*
        Zone GK-A master gateway list:
        172.22.1.1:1720 GW-A1

Hinweis: Anstatt den Befehl h323-gateway voip tech-prefix 1# mit dem Befehl h323-gateway zu konfigurieren, kann dieser auf dieselbe Weise durchgeführt werden, indem diese Informationen im GK-A manuell mit dem Befehl konfiguriert werden.

GK-A(config-gk)#gw-type-prefix 1#* gw ipaddr 172.22.1.1

Anrufaktion: Benutzer A2 wählt 512-555-1212, um Benutzer A1 anzurufen.

GK-A empfängt ARQ von GWY-A2.

1. Stimmt das Technologiepräfix überein? Ja

   Hinweis: Nach der Übereinstimmung des Technologiepräfixes entfernt der Gatekeeper das Präfix für die Zone, um es zu analysieren. Dieser Streifen wird nur von der Gatekeeper-Analyse durchgeführt. Das ursprüngliche Gateway hängt es weiterhin in der Anrufeinrichtung an das Terminierungs-Gateway an.

2. Stimmt das Zonenpräfix überein? Ja. Legen Sie die Zielzone auf die Ebene der lokalen Zone fest.

3. Stimmt der Aliasname (nach dem Entfernen des technischen Präfix) mit einem registrierten GW überein? Nein. (Wenn ja, senden Sie ACF.)

4. Ist die Zielzone lokal? Ja

5. Wurde in Schritt 1 ein Technologiepräfix gefunden? Ja

6. Wurde ein lokales Gateway mit einem Technologiepräfix gefunden? Ja. Senden Sie ACF.

   Erfolgreiche Anrufeinrichtung.

Diese GK-A-Debug-Befehlsausgabe veranschaulicht das obige Verhalten.

Hinweis: Dieser Debugbefehl ist nützlich, aber ausgeblendet, Debuggen. Daher zeigt der Parser das Debuggen nicht an.

GK-A#debug gatekeeper main 5
      
    *Jun 19 09:50:10.086: gk_rassrv_arq: arqp=0x631CC400, crv=0x82, answerCall=0
    *Jun 19 09:50:10.086: gk_dns_locate_gk(): No Name servers
    *Jun 19 09:50:10.086: rassrv_get_addrinfo(1#5125551010): Matched tech-prefix 1#
    *Jun 19 09:50:10.086: rassrv_get_addrinfo(1#5125551010): Matched zone prefix 512
    *Jun 19 09:50:10.118: gk_rassrv_arq: arqp=0x631CC400, crv=0x1A, answerCall=1

Hinweis: Dies ist eine alternative Konfiguration, die intuitiver sein kann:

• Geben Sie den Befehl h323-gateway voip tech-prefix 512 aus, um GWY-A1 für die Registrierung mit dem Technologiepräfix 512 zu konfigurieren.

• Auf diese Weise muss GWY-A2 das Präfix im VoIP-Dial-Peer-Anrufabschnitt nicht übergeben, da das Zielmuster bereits 512 umfasst. Nehmen Sie daher den Befehl tech-prefix 1# in der Konfiguration GWY-A2 heraus, und entfernen Sie 1# unter dem DFÜ-Peer für POTS auf GWY-A1 aus dem Zielmuster.

Szenario 3: Konfigurierte Standard-Technologiepräfixe

In diesem Szenario wird GWY-A1 mit dem Technologiepräfix 1# registriert, und GK-A ist so konfiguriert, dass Anrufe weitergeleitet werden, ohne dass das Technologiepräfix mit den standardmäßigen Technologie-Präfix-Gateways übereinstimmt. Aus diesem Grund muss GWY-A2 nicht so konfiguriert werden, dass das Ziel-Technologiepräfix übergeben wird.

!
gatekeeper
zone local GK-A abc.com
zone prefix GK-A 512.......
zone prefix GK-A 972.......
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix 
no shutdown
!

!
interface Ethernet0/0 
ip address 172.22.1.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A1@abc.com 
h323-gateway voip tech-prefix 1# 
!
dial-peer voice 1 pots
destination-pattern 512.......
direct-inward-dial
port 1/0:23
prefix 512
!
dial-peer voice 2 voip
destination-pattern 972.......
session target ras
!
gateway
!

!
dial-peer voice 1 voip
destination-pattern 512.......
session target ras
!
dial-peer voice 2 pots
destination-pattern 9725551010
port 1/0/0
!
gateway
!
interface FastEthernet0/0
ip address 172.22.1.2 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A2@abc.com
!

Diese auf GK-A erfasste Ausgabe zeigt die registrierten Technologiepräfixe an:

GK-A#show gatekeeper gw-type-prefix
        
        GATEWAY TYPE PREFIX TABLE
        =========================
        Prefix: 1#* (Default gateway-technology)
        Zone GK-A master gateway list:
        172.22.1.1:1720 GW-A1

Anrufaktion: Benutzer A2 wählt 512-555-1212, um Benutzer A1 anzurufen.

GK-A empfängt ARQ von GWY-A2.

1. Stimmt das Technologiepräfix überein? Nein

2. Stimmt das Zonenpräfix überein? Ja. Legen Sie die Zielzone auf die Ebene der lokalen Zone fest.

3. Ist die Zielzone lokal? Ja

4. Wurde in Schritt 1 ein Technologiepräfix gefunden? Nein

5. Ist die Zieladresse registriert? Nein

6. Ist das technische Standardpräfix festgelegt? Ja. Wählen Sie das lokale Gateway mit dem Technologiepräfix (nur eines verfügbar) aus.

7. Senden Sie ACF.

   Einrichtung des Anrufs erfolgreich.

Beispiele für Remote Zone-Anrufe

In diesen Beispielen gibt es zwei H.323-Zonen: eine wird von GK-A und eine andere von GK-B kontrolliert.

In den Szenarien in diesem Abschnitt wird der schrittweise Entscheidungsprozess erläutert, den die Gatekeeper verwenden, um Anrufe basierend auf den ARQ- und LRQ-Nachrichten weiterzuleiten.

Hinweis: In diesen Konfigurationsbeispielen wird nur relevante Ausgabe angezeigt.

Szenario 1: Zone Gatekeepers, konfiguriert mit standardmäßigen Technologie-Präfixen

In diesem Szenario registriert sich GWY-A1 mit dem Technologiepräfix 1# bei GK-A und GWY-B1 mit dem Technologiepräfix 2# bei GK-B. Beide Gatekeeper sind mit standardmäßigen Technologie-Präfix-Gateways konfiguriert.

!
gatekeeper
zone local GK-A abc.com 172.22.1.3
zone remote GK-B abc.com 172.22.2.3 1719
zone prefix GK-B 214.......
zone prefix GK-A 512.......
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
! 

!
gatekeeper
zone local GK-B abc.com 172.22.2.3
zone remote GK-A abc.com 172.22.1.3 1719
zone prefix GK-B 214.......
zone prefix GK-A 512.......
gw-type-prefix 2#* default-technology
no shutdown
!

!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0
half-duplex
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A1@abc.com
h323-gateway voip tech-prefix 1#
!
dial-peer voice 1 pots
destination-pattern 512.......
direct-inward-dial
port 1/0:23
prefix 512
!
dial-peer voice 2 voip
destination-pattern ..........
session target ras
!
gateway

!
interface Ethernet0/0
ip address 172.22.2.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-B ipaddr 172.22.2.3 1718
h323-gateway voip h323-id GWY-B1@abc.com
h323-gateway voip tech-prefix 2#
!
dial-peer voice 1 pots
destination-pattern 214.......
direct-inward-dial
port 3/0:23
prefix 214
!
dial-peer voice 2 voip
destination-pattern T
session target ras
!
gateway
!

Anrufaktion: Benutzer A1 wählt 214-555-1111, um Benutzer B1 anzurufen.

GK-A empfängt ARQ von GWY-A1.

1. Stimmt das Technologiepräfix überein? Nein

2. Stimmt das Zonenpräfix überein? Ja. Legen Sie die Zielzone auf die Ebene der entfernten GK-B-Zone fest (214).

3. Ist die Zielzone lokal? Nein

4. Senden Sie LRQ an GK-B.

GK-B empfängt LRQ von GK-A.

1. Stimmt das Technologiepräfix überein? Nein

2. Stimmt das Zonenpräfix überein? Ja. Legen Sie die Zielzone auf die Ebene der lokalen Zone fest.

3. Ist die Zielzone lokal? Ja

4. Wurde in Schritt 1 ein Technologiepräfix gefunden? Nein

5. Ist die Zieladresse registriert? Nein

6. Ist das technische Standardpräfix festgelegt? Ja. Wählen Sie das lokale Gateway mit dem Technologiepräfix (2#) aus.

7. Senden Sie LCF an GK-A.

   GK-A empfängt LCF von GK-B mit Terminierungs-Gateway-Informationen.

   GK-A sendet ACF an GWY-A1.

   Die Anrufeinrichtung ist erfolgreich.

Szenario 2: Zone Gatekeepers konfiguriert, ohne standardmäßige Technologie-Präfixe

In diesem Szenario registriert sich GWY-A1 mit dem Technologiepräfix 1# bei GK-A und GWY-B1 mit dem Technologiepräfix 2# bei GK-B. GWY-A1 fügt der angerufenen Zahlenzeichenfolge beim Tätigen von Anrufen an (214) das Technologiepräfix 2# hinzu, und GWY-B1 fügt der angerufenen Zahlenzeichenfolge beim Tätigen von Anrufen an (512) das Technologiepräfix 1# hinzu.

!
gatekeeper
zone local GK-A abc.com
zone remote GK-B abc.com 172.22.2.3 1719
zone prefix GK-B 214*
zone prefix GK-A 512*
arq reject-unknown-prefix
no shutdown
!

!
gatekeeper
zone local GK-B abc.com 172.22.2.3
zone remote GK-A abc.com 172.22.1.3 1719
zone prefix GK-B 214*
zone prefix GK-A 512*
no shutdown
!

!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0
half-duplex
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A1@abc.com
h323-gateway voip tech-prefix 1#
!
dial-peer voice 1 pots
destination-pattern 512.......
direct-inward-dial
port 1/0:23
prefix 512
!
dial-peer voice 2 voip
destination-pattern 214.......
session target ras
tech-prefix 2# 
!
gateway

!
interface Ethernet0/0
ip address 172.22.2.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-B ipaddr 172.22.2.3 1718
h323-gateway voip h323-id GWY-B1@abc.com
h323-gateway voip tech-prefix 2#
!
dial-peer voice 1 pots
destination-pattern 214.......
direct-inward-dial
port 3/0:23
prefix 214
!
dial-peer voice 2 voip
destination-pattern T
session target ras
tech-prefix 1# 
!
gateway
!

Erste Anrufaktion: Benutzer B1 wählt 512-555-1212, um Benutzer A1 anzurufen.

GK-B empfängt ARQ von GWY-B1.

1. Stimmt das Technologiepräfix überein? Nein

2. Stimmt das Zonenpräfix überein? Nein

   Hinweis: Da GK-B kein 1#-Technologiepräfix kennt, wird davon ausgegangen, dass es Teil der angerufenen Nummer ist und als Zonenpräfix liest.

3. Ist die Zielzone lokal? Ja

   Hinweis: GK-B übernimmt die Standardzielzone gleich der lokalen Zone, da der Befehl arq reject-known-prefix nicht festgelegt ist.

4. Wurde in Schritt 1 ein Technologiepräfix gefunden? Nein

5. Ist die Zieladresse registriert? Nein

6. Ist das technische Standardpräfix festgelegt? Nein

7. Senden Sie ARJ an GWY-B1.

   Einrichtung des Anrufs fehlgeschlagen.

Diese Ausgabe wurde in GK-B erfasst, um dieses Verhalten genauer zu veranschaulichen:

!--- From debug gatekeeper main 5.

      
GK-B#
gk_rassrv_arq: arqp=0x62F6A7E0, crv=0x22, answerCall=0
gk_dns_locate_gk(): No Name servers
rassrv_get_addrinfo(1#5125551212): Tech-prefix match failed
rassrv_get_addrinfo(1#5125551212): unresolved zone prefix, using source zone GK-B
rassrv_get_addrinfo(1#5125551212): unknown address and no default technology defined
gk_rassrv_sep_arq(): rassrv_get_addrinfo() failed (return code = 0x103)

!--- From debug ras.


GK-B#
RecvUDP_IPSockData successfully rcvd message of length 156 from 172.22.2.1:51141
ARQ (seq# 1796) rcvdparse_arq_nonstd: ARQ Nonstd decode succeeded, remlen= 156
IPSOCK_RAS_sendto: msg length 4 from 172.22.2.3:1719 to 172.22.2.1: 51141
RASLib::RASSendARJ: ARJ (seq# 1796) sent to 172.22.2.1

Konfigurieren Sie die Gatekeeper so, dass sie die technologischen Präfixe der Remote-Zone identifizieren, um dieses Problem zu beheben.

• Fügen Sie dies GK-B hinzu:

  GK-B(config-gk)#gw-type-prefix 1# hopoff GK-A
  

• Fügen Sie dies GK-A hinzu:

  GK-A(config-gk)#gw-type-prefix 2# hopoff GK-B
  

Beachten Sie, dass der POTS-DFÜ-Peer in den terminierenden Gateways aktualisiert werden musste, um die eingehenden Wählzeichenfolgen mit den Technologie-Präfixen abzustimmen.

!
gatekeeper
zone local GK-A abc.com
zone remote GK-B abc.com 172.22.2.3 1719
zone prefix GK-B 214*
zone prefix GK-A 512*
arq reject-unknown-prefix
gw-type-prefix 2# hopoff GK-B
no shutdown
!

!
gatekeeper
zone local GK-B abc.com 172.22.2.3
zone remote GK-A abc.com 172.22.1.3 1719
zone prefix GK-B 214*
zone prefix GK-A 512*
gw-type-prefix 1# hopoff GK-A
no shutdown
!

!
interface Ethernet0/0
ip address 172.22.1.1 255.255.255.0
half-duplex
h323-gateway voip interface
h323-gateway voip id GK-A ipaddr 172.22.1.3 1718
h323-gateway voip h323-id GW-A1@abc.com
h323-gateway voip tech-prefix 1#
!
 !--- This dial-peer is used for !--- incoming calls from the PSTN.

dial-peer voice 1 pots
incoming called-number 512.......
direct-inward-dial
port 1/0:23
!
dial-peer voice 2 voip
destination-pattern 214.......
session target ras
tech-prefix 2# 
!

!--- This dial-peer is used to !--- terminate (512) calls coming !--- from the VoIP network. Notice !--- that the technology prefix !--- is matched to select the dial-peer !--- but does not pass it to !--- the PSTN.
 
dial-peer voice 3 pots
destination-pattern 1#512.......
direct-inward-dial
port 1/0:23
prefix 512
!
dial-peer voice 4 voip
destination-pattern 972.......
session target ras
! 
gateway

!
interface Ethernet0/0
ip address 172.22.2.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GK-B ipaddr 172.22.2.3 1718
h323-gateway voip h323-id GWY-B1@abc.com
h323-gateway voip tech-prefix 2#
!
dial-peer voice 1 pots
incoming called-number 214.......
direct-inward-dial
port 3/0:23
prefix 214
!
dial-peer voice 2 voip
destination-pattern T
session target ras
tech-prefix 1# 
!
dial-peer voice 3 pots
destination-pattern 2#214....... 
port 3/0:23
prefix 214 
! 
gateway
!

Zweite Anrufaktion: Benutzer B1 wählt 512-555-1212, um Benutzer A1 anzurufen.

GK-B empfängt ARQ von GWY-B1.

1. Stimmt das Technologiepräfix überein? Ja

2. Gibt es ein Hop-Off-Technologiepräfix? Ja

3. Senden Sie LRQ an GK-A.

   Hinweis: Der LRQ enthält das Technologiepräfix in der angerufenen Nummer für die GK-A-Analyse.

GK-A empfängt LRQ von GK-B.

1. Stimmt das Technologiepräfix überein? Ja

2. Gibt es ein Hop-Off-Technologiepräfix? Nein

   Hinweis: Um die Anrufweiterleitungsanalyse fortzusetzen, entfernt GK-A das Technologiepräfix. Das Technologiepräfix verbleibt in der angerufenen Zahlenfolge, wenn die Gateways die Anrufabschnitte einrichten.

3. Stimmt das Zonenpräfix überein? Ja. Legen Sie die Zielzone auf die Ebene der lokalen Zone fest.

4. Ist die Zielzone lokal? Ja

5. Wurde in Schritt 1 ein Technologiepräfix gefunden? Ja

6. Haben Sie ein lokales Gateway mit einem Technologiepräfix gefunden? Ja

7. Senden Sie LCF an GK-B.

   GK-B empfängt LCF von GK-A mit Terminierungs-Gateway-Informationen.

   GK-B sendet ACF an GWY-B1.

   Einrichtung des Anrufs erfolgreich.

Diese Befehlsausgabe wurde in GK-B erfasst, um dieses Verhalten genauer zu veranschaulichen:

!--- From debug gatekeeper main 5.


GK-B#
gk_rassrv_arq: arqp=0x62ED2D68, crv=0x24, answerCall=0
gk_dns_locate_gk(): No Name servers
rassrv_get_addrinfo(1#5125551212): Matched tech-prefix 1#
rassrv_put_remote_zones_from_zone_list() zone GK-A
gk_rassrv_irr: irrp=0x62F0D8FC, from 172.22.2.1:51141
GK-B#
GK-B#

!--- From debug ras.


RecvUDP_IPSockData successfully received message of 
length 156 from 172.22.2.1:51141
ARQ (seq# 1809) rcvdparse_arq_nonstd: ARQ Nonstd decode 
succeeded, remlen= 156
IPSOCK_RAS_sendto: msg length 104 from 
172.22.2.3:1719 to 172.22.1.3: 1719
RASLib::RASSendLRQ: LRQ (seq# 1042) sent to 172.22.1.3
IPSOCK_RAS_sendto: msg length 7 from 172.22.2.3:1719 to 172.22.2.1: 51141
RASLib::RASSendRIP: RIP (seq# 1809) sent to 172.22.2.1
RecvUDP_IPSockData successfully rcvd message of length 
131 from 172.22.1.3:1719
LCF (seq# 1042) rcvdparse_lcf_nonstd: LCF Nonstd 
decode succeeded, remlen= 131
IPSOCK_RAS_sendto: msg length 34 from 172.22.2.3:1719 
to 172.22.2.1: 51141
RASLib::RASSendACF: ACF (seq# 1809) sent to 172.22.2.1
RecvUDP_IPSockData successfully rcvd message of length 
76 from 172.22.2.1:51141

Befehle zur Überprüfung und Fehlerbehebung

Dieser Abschnitt enthält eine Liste der Befehle zum Anzeigen und Debuggen, mit denen Gatekeeper- und Gateway-Anrufweiterleitungsprobleme überprüft und behoben werden können.

Das Output Interpreter Tool (nur registrierte Kunden) (OIT) unterstützt bestimmte show-Befehle. Verwenden Sie das OIT, um eine Analyse der Ausgabe des Befehls show anzuzeigen.

Hinweis: Beachten Sie vor der Verwendung von Debug-Befehlen die Informationen zu Debug-Befehlen.

• show gateway - Wird zur Überprüfung der E.164- und H.323-Aliasregistrierung für das Gateway verwendet.

• show gatekeeper endpoints - Dient zum Überprüfen der beim Gatekeeper registrierten E.164- und H.323-Alias.

• show gatekeeper gw-type-prefix - Wird zum Überprüfen der E.164-Präfixregistrierung auf dem Gatekeeper verwendet.

• Präfix der Gatekeeper-Zone anzeigen | status - Dient zum Überprüfen des Zonenstatus und der Konfigurationsparameter.

• debug ras - Gilt für Gateways und Gatekeepers.

• debug h225 asn1: Gilt für Gateways und Gatekeeper.

• show dial-peer voice - wird verwendet, um konfigurierte Technologie-Präfixe unter den DFÜ-Peers zu überprüfen.

Zugehörige Informationen

• H.323-Gatekeepers
• Fehlerbehebung bei Gatekeeper-Registrierungsproblemen
• Voice - Verständnis dafür, wie Peers für eingehende und ausgehende Anrufe auf Cisco IOS-Plattformen übereinstimmen
• Unterstützung von Sprachtechnologie
• Produkt-Support für Sprach- und Unified Communications
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support und Dokumentation - Cisco Systems