Konfigurieren von MGCP-Gateways und Fehlerbehebung
Inhalt
Einleitung
In diesem Dokument wird die Konfiguration und Fehlerbehebung des Media Gateway Control Protocol (MGCP) beschrieben. MGCP ist ein Anruf-Agent-/Endpunkt-Protokoll.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
- VG 320
- Cisco Unified Communications Manager 11.5
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Gemeinsame Definitionen
| Attribut |
Definition |
| Anruf-Agent |
Die Elemente der Anrufsteuerung, die die primäre Rolle spielen und zentralisierte Anrufintelligenz bereitstellen. |
| Endgeräte |
Die Endpunkte sind die Geräte, die die Anruf-Agenten steuern, z. B.: FXO, FXS oder ein DS0-Kanal. |
| PSTN |
Öffentliches Telefonnetz. |
MGCP-Grundlagen
Das Media Gateway Control Protocol (MGCP) wird in RFC 2705 definiert. Das MGCP ist ein Anruf-Agent/Endpunkt-Protokoll, bei dem der Endpunkt von einem Anruf-Agent eines Typs gesteuert wird. Die gesamte Steuerungsintelligenz wird von einem Call Agent verwaltet, der den Endpunkt anweist, welche Aktion er nach dem Erkennen eines Ereignisses ausführen soll. MGCP verwendet den TCP-Port 2428 und den UDP-Port 2427.
Über den TCP-Port 2428 im MGCP wird ein neuer Socket mit dem Call Agent geöffnet, um festzustellen, ob die Verbindung hergestellt werden kann. Ohne diesen neuen Socket können nachfolgende MGCP-Nachrichten nicht ausgetauscht werden. Er wird auch zum Senden/Empfangen von Backhaul-Nachrichten zwischen PRI-Endpunkten und dem Anruf-Agenten verwendet, bei dem er registriert ist. Schließlich wird über den TCP-Port 2428 ein Failover auf Backup-Call Agents durchgeführt, falls ein Primary Call Agent nicht reagiert.
Der UDP-Port 2427 im MGCP wird für MGCP-Nachrichten verwendet, die zwischen den Endpunkten und den Anruf-Agenten ausgetauscht werden.
Grundlegender Flow
Dies ist ein Beispiel für einen grundlegenden MGCP-Fluss. In diesem Beispiel empfängt das Gateway einen neuen Anruf vom PSTN auf diesem Sprach-Gateway (Endpunkt). Das Gateway benachrichtigt den Anruf-Agenten (CUCM) über diesen neuen Anruf, der eingeht. Der Anruf-Agent weist das Gateway an, eine Verbindung für diesen neuen Anruf herzustellen. Schließlich sendet das Gateway ein OK zurück an den Anruf-Agenten, um den Anruf zu tätigen.
Endgerätidentifikatoren
Der Anruf-Agent benötigt eine Kennung pro Endpunkt, um zu bestimmen, wer ein Ereignis senden muss oder woher ein Ereignis stammt. Endpoint Identifier umfassen zwei Hauptkomponenten:
- Lokaler Name innerhalb dieses Gateways (Groß- und Kleinschreibung wird nicht berücksichtigt).
- Domänenname des Gateways, das den Endpunkt verwaltet (Groß- und Kleinschreibung beachten).
Beispiele:
- AALN/S1/SU0/0@AV-VG200-2.cisco.com
- S0/SU0/DS1-0@AV-VG200-1
Grundkonfiguration des MGCP
In diesem Dokument sind die einzelnen Konfigurationskomponenten in einzelne Schritte unterteilt.
Gateway-CLI-Konfiguration
Dies ist die erforderliche Mindestkonfiguration auf dem analogen Gateway, das Sie für CUCM registrieren möchten. Sie müssen nur diese Konfiguration hinzufügen, um den Registrierungsprozess zu starten, da die verbleibende Konfiguration von CUCM heruntergeladen wird:
VG320(config)# mgcp call-agent 10.50.217.100 2427 service-type mgcp version 0.1 VG320(config)# ccm-manager config server 10.50.217.100 VG320(config)# ccm-manager config VG320(config)# ccm-manager mgcp VG320(config)# mgcp **Note on the ISR4000s if you fail to down load your configuration file, you must add the command: VG320(config)# ip tftp source-interface GigabitEthernet x/x/x
Konfiguration des CUCM
Schritt 1: Um das MGCP-Gateway in CUCM zu konfigurieren, müssen Sie sich bei der Cisco Unified CM-Verwaltung anmelden. Navigieren Sie nach der Anmeldung zu Device > Gateway (Gerät > Gateway):
Schritt 2: Bei der vorherigen Auswahl gelangen Sie zur Seite Gateway suchen und auflisten. Wählen Sie auf dieser Seite die Schaltfläche Add New (Neu hinzufügen) mit einem "+" (Plus)-Zeichen:
Schritt 3. Nachdem Sie Add New (Neu hinzufügen) ausgewählt haben, werden Sie aufgefordert, einen Gateway Type (Gateway-Typ) auszuwählen. Wählen Sie im Dropdown-Menü die Hardware aus, die Sie registrieren möchten, und wählen Sie Weiter aus, um das gewünschte Protokoll für dieses Gerät auszuwählen (Sie müssen MGCP auswählen):
Schritt 4: Nachdem Sie die verwendete Hardware und das verwendete Protokoll ausgewählt haben, müssen Sie den Domänennamen, die Cisco Unified Communications Manager-Gruppe und die Modulinformationen konfigurieren. Dies sind die Hauptfelder, die zum Registrieren eines Endpunkts über MGCP erforderlich sind.
Schritt 5: Der Domänenname besteht aus 1 bis 2 Teilen. Geben Sie mindestens im Feld Domain Name (Domänenname) den Hostnamen des Routers ein. In diesem Szenario lautet der Hostname:
VG320. Wenn Sie jedoch einen Domänennamen auf dem Gateway konfiguriert haben, müssen Sie den vollqualifizierten Domänennamen dieses Geräts konfigurieren:
Schritt 6. Wählen Sie Speichern. Dadurch wird die Seite aktualisiert, und Sie können eine Untereinheit auswählen. Wenn Sie eine Untereinheit ausgewählt haben, wählen Sie erneut Speichern aus. Sie können nun Ihre konfigurierbaren Ports anzeigen:
Schritt 7: Um einen Endpunkt zu konfigurieren, klicken Sie auf den Port, an den das analoge Gerät angeschlossen ist (in diesem Szenario 0/0/0). Nachdem Sie einen Port ausgewählt haben, werden Sie aufgefordert, den Port-Typ zu konfigurieren:
Schritt 8: Wählen Sie in diesem Fall POTS aus. Nach der Auswahl können Sie alle erforderlichen Werte für die Geräteinformationen wie für jeden anderen Call Manager-Endpunkt eingeben. Das einzige erforderliche Feld ist der Gerätepool. Sie können jedoch zusätzliche Werte eingeben, z. B. den Calling Search Space. Klicken Sie abschließend auf Speichern.
Schritt 9. An diesem Punkt hat der linke Fensterausschnitt das Feld Neue DN hinzufügen ausgefüllt. Sie können nun eine DN diesem Port zuordnen, speichern und die Konfiguration anwenden. Sobald dies abgeschlossen ist, können Sie den Port auf der Seite für die Portkonfiguration als registriert anzeigen:
Endpunktregistrierung und Anrufeinrichtung
In diesem Abschnitt werden die Grundlagen der MGCP-Endpunktregistrierung und der Anrufeinrichtung behandelt. Dies schließt die Befehlsmeldungen ein, die als Interaktion des Gateways mit dem Anruf-Agenten angesehen werden. In diesem Szenario ist CUCM unser Call Agent.
MGCP-Endpunktregistrierung
Damit sich ein MGCP-Endpunkt beim CUCM registrieren kann, öffnet das Gateway den TCP-Socket 2428 für den CUCM. Von hier aus verwendet es den UDP-Port 2427, um Befehlsmeldungen zu senden. Sobald der Socket geöffnet ist, sendet das Gateway einen RSIP-Befehl an den CUCM, um zu informieren, dass der Endpunkt während des Neustarts außer Betrieb genommen werden muss. Der CUCM sendet hierzu eine einfache Bestätigung. Nach Abschluss des Neustarts sendet der CUCM eine RQNT mit dem Parameter R: L/H Dies bedeutet, dass das Gateway den CUCM über ein "Off-Hook"-Ereignis informieren muss.
An diesem Punkt sendet der CUCM einen Audit Endpoint (AUEP) an das Gateway, um den Status des angegebenen Endpunkts zu bestimmen. Die Antwort vom Gateway ist ein ACK mit den Endgerätefunktionen. Anschließend wird der Endpunkt beim CUCM registriert. Dies ist eine Beispiel-Debugausgabe:
000138: *Apr 23 19:41:49.010: MGCP Packet sent to <CUCM IP>:2427---> RSIP 39380951 aaln/S0/SU0/0@VG320.dillbrowLab.local MGCP 0.1 RM: restart <--- 000139: *Apr 23 19:41:49.030: MGCP Packet received from <CUCM IP>:2427---> 200 39380951 <--- 000140: *Apr 23 19:41:49.030: MGCP Packet received from <CUCM IP>:2427---> RQNT 3 AALN/S0/SU0/0@VG320.dillbrowLab.local MGCP 0.1 X: 2 R: L/hd Q: process,loop <--- 000141: *Apr 23 19:41:49.030: MGCP Packet sent to <CUCM IP>:2427---> 200 3 OK <--- 000142: *Apr 23 19:41:49.050: MGCP Packet received from <CUCM IP>:2427---> AUEP 4 AALN/S0/SU0/0@VG320.dillbrowLab.local MGCP 0.1 F: X, A, I <--- 000143: *Apr 23 19:41:49.050: MGCP Packet sent to <CUCM IP>:2427---> 200 4 I: X: 2 L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-110, a:G.726-16;G.728, b:16, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-70, a:G.726-24, b:24, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-50, a:G.726-32, b:32, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest <---
Einrichtung von MGCP-Anrufen
Das vorherige Bild zeigt einen ausgehenden Anruf.
Sie können sehen, dass Ihr Anruf-Agent, in diesem Fall CUCM, mit einer CRCX beginnt, die nur zum Gateway zurückgekehrt ist, um die Verbindung für den Anruf herzustellen. Das Gateway antwortet mit einem OK von 200, das SDP für das enthält, was es unterstützt. Nachdem dieser Austausch erfolgt ist, sendet der CUCM eine RQNT-Nachricht an das Gateway mit dem Parameter S: G/rt. Dadurch wird das Gateway angewiesen, den Rückruf auf dem Gerät wiederzugeben. Nachdem der Gesprächspartner den Anruf empfangen und entgegengenommen hat, sendet CUCM einen MDCX mit SDP an das Gateway, um ihm die Medieninformationen für das Gesprächspartner-Gerät mitzuteilen. Das Gateway sendet eine einfache 200 OK zurück, um dies zu bestätigen, und an diesem Punkt haben Sie Zwei-Wege-Medien eingerichtet.
Nachdem der Anruf beantwortet wurde, sendet der CUCM eine weitere RQNT mit dem Parameter R: D/[0-9ABCD*#]. Dadurch wird das Gateway angewiesen, dem CUCM alle DTMF-Töne mitzuteilen, die bei aktivem Anruf gedrückt werden, damit der Anruf an das nächste Gerät weitergeleitet werden kann.
Nach Beendigung des Anrufs sendet der CUCM einen MDCX an das Gateway mit M: recvonly, um das Medium zu beenden, gefolgt von einem DLCX, um den Anruf zu trennen. Dies ist eine Beispiel-Debugausgabe:
001005: *May 13 14:28:15.633: MGCP Packet received from <CUCM IP>:2427---> CRCX 174 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 C: A000000001b79063000000F5 X: 21 L: p:20, a:PCMU, s:off, t:b8 M: recvonly R: L/hu Q: process,loop <--- 001006: *May 13 14:28:15.637: MGCP Packet sent to <CUCM IP>:2427---> 200 174 OK I: 6 v=0 c=IN IP4 <Gateway IP> m=audio 16410 RTP/AVP 0 101 100 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 <--- 001007: *May 13 14:28:15.789: MGCP Packet received from <CUCM IP>:2427---> RQNT 175 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 X: 22 R: L/hu S: G/rt Q: process,loop <--- 001008: *May 13 14:28:15.789: MGCP Packet sent to <CUCM IP>:2427---> 200 175 OK <--- 001009: *May 13 14:28:17.793: MGCP Packet received from <CUCM IP>:2427---> MDCX 176 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 C: A000000001b79063000000F5 I: 6 X: 23 L: p:20, a:PCMU, s:off, t:b8 M: sendrecv R: L/hu, L/hf, D/[0-9ABCD*#] S: Q: process,loop v=0 o=- 6 0 IN EPN AALN/S0/SU1/0@VG320.dillbrowLab.local s=Cisco SDP 0 t=0 0 m=audio 18946 RTP/AVP 0 101 c=IN IP4 <Phone IP> a=rtpmap:101 telephone-event a=fmtp:101 0-15 <--- 001010: *May 13 14:28:17.797: MGCP Packet sent to <CUCM IP>:2427---> 200 176 OK <--- 001011: *May 13 14:28:17.797: MGCP Packet received from <CUCM IP>:2427---> RQNT 177 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 X: 24 R: L/hu, D/[0-9ABCD*#], L/hf S: Q: process,loop <--- 001012: *May 13 14:28:17.797: MGCP Packet sent to <CUCM IP>:2427---> 200 177 OK <--- 001015: *May 13 14:28:20.813: MGCP Packet received from <CUCM IP>:2427---> DLCX 178 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 C: A000000001b79063000000F5 I: 6 X: 25 R: L/hd S: Q: process,loop <--- 001016: *May 13 14:28:20.845: MGCP Packet sent to <CUCM IP>:2427---> 250 178 OK P: PS=151, OS=24160, PR=146, OR=23360, PL=0, JI=0, LA=0 <---
Fehlerbehebung bei MGCP
Wenn Sie die MGCP-Fehlerbehebung durchführen, gibt es hilfreiche Befehle zum Anzeigen und Debuggen, die Sie anzeigen können, um festzustellen, warum die Registrierung oder ein Anruf fehlgeschlagen ist. Am besten überprüfen Sie zunächst, ob Ihr MGCP-Gateway beim Call Agent registriert ist. Sie können überprüfen, indem Sie den Befehl show show ccm-manager oder show mgcp ausführen:
VG320# show ccm-manager MGCP Domain Name: VG320.dillbrowLab.local Priority Status Host ============================================================ Primary Registered <CUCM IP> First Backup None Second Backup None Current active Call Manager: <CUCM IP> Backhaul/Redundant link port: 2428 Failover Interval: 30 seconds Keepalive Interval: 15 seconds Last keepalive sent: 17:42:40 UTC Jul 12 2019 (elapsed time: 00:00:15) Last MGCP traffic time: 17:42:55 UTC Jul 12 2019 (elapsed time: 00:00:00) VG320# show mgcp MGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONE MGCP call-agent: <CUCM IP> 2427 Initial protocol service is MGCP 0.1 MGCP validate call-agent source-ipaddr DISABLED MGCP validate domain name DISABLED MGCP block-newcalls DISABLED
Diese Befehle wurden gekürzt, um nur die entsprechende Ausgabe zu enthalten. Weitere Informationen finden Sie in den folgenden Ausgängen:
- MGCP anzeigen
- MGCP-Endpunkt anzeigen
- MGCP-Verbindung anzeigen
- show ccm-manager
- Übersicht der Sprachports
- ISDN-Status anzeigen
- show controller [t1/e1] x/x/x
- Anzeige der aktiven Sprachnachrichten
- Übersicht über Sprachanrufe anzeigen
- Anzeige des Sprachanrufstatus
Wenn die vorherigen Befehle show auschecken, können Sie diese Debugs auf dem Gerät ausführen, um zu ermitteln, warum der Aufruf fehlgeschlagen ist:
- debug mgcp [Endpunkt | Fehler | Veranstaltungen | Pakete]
- debug mgcp all (für erweitertes Debugging)
- debug ccm-manager [Backhaul] | Konfig.-Download | Fehler | Veranstaltungen]
- debuggen voip ccapi inout
- debug vpm-Signal
- debug voip vtsp session
- debug isdn q931
Die vorherigen Fehlerbehebungen sind ein guter Ausgangspunkt für die Behebung von Registrierungs- und Anrufeinrichtungsproblemen.
Zugehörige Informationen
- RFC 2705: Data Tracker - Notification Request
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
5.0 |
02-Jul-2026
|
Rechtschreibung, Abstand und 1 Alternativtext aktualisiert. |
4.0 |
29-Aug-2023
|
PII, SEO, Branding-Anforderungen und Formatierung aktualisiert. |
3.0 |
15-Jul-2022
|
Rezertifizierung |
1.0 |
14-Aug-2019
|
Erstveröffentlichung |
Feedback