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
- Cisco Unified Communications Manager 11.5
- VG 320
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
Hinweis: In diesem Dokument werden Konfigurationsbeispiele sowie Debug- und Anzeigebefehlsausgaben als Bezugspunkte verwendet. Die zahlreichen Funktionen in diesem Dokument sind klar mit der Version gekennzeichnet, in der die Funktion sowohl in Cisco IOS® als auch in Cisco IOS® XE eingeführt wurde.
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 von den Anruf-Agenten gesteuert werden. Beispiele: FXO, FXS oder ein DS0-Kanal. |
PSTN |
Öffentliches Telefonnetz. |
MGCP-Grundlagen
Das Media Gateway Control Protocol (MGCP) wird in RFC 2705 definiert. MGCP ist ein Anruf-Agent/Endpunkt-Protokoll, bei dem der Endpunkt von einem Anruf-Agenten eines Typs gesteuert wird. Die gesamte Steuerungsintelligenz wird von einem Call Agent gesteuert, 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. Wie Sie im Beispiel sehen, erhält das Gateway einen neuen Anruf vom PSTN auf diesem Voice Gateway (Endpoint). Das Gateway benachrichtigt dann den Anruf-Agenten (CUCM) über diesen neuen Anruf, der eingeht. Anschließend weist der Anruf-Agent 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 bestimmen zu können, wer ein Ereignis senden muss oder woher ein Ereignis stammt. Endgeräte-IDs bestehen im Wesentlichen aus zwei Komponenten:
- 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
Auf dem analogen Gateway, das Sie für CUCM registrieren möchten, ist dies die erforderliche Mindestkonfiguration. Sie müssen nur diese Konfiguration hinzufügen, um den Registrierungsprozess zu starten, da die restliche Konfiguration dann 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
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):
Die vorherige Auswahl beginnt mit der Seite Gateway suchen und auflisten. Wählen Sie dazu die Schaltfläche Neu hinzufügen mit einem Pluszeichen:
Nachdem Sie Add New (Neu hinzufügen) ausgewählt haben, werden Sie aufgefordert, einen Gateway Type (Gateway-Typ) auszuwählen. Verwenden Sie dieses Dropdown-Menü, um die Hardware auszuwählen, die Sie registrieren möchten, und wählen Sie Weiter, um das gewünschte Protokoll für dieses Gerät auszuwählen (Sie müssen MGCP auswählen):
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.
Der Domänenname besteht aus 1 bis 2 Teilen. Geben Sie mindestens im Feld Domain Name (Domänenname) den Hostnamen des Routers ein. In meinem Szenario lautet der Hostname wie folgt:
VG 320
Wenn Sie jedoch einen Domänennamen auf dem Kabelmodem konfiguriert haben, müssen Sie den vollqualifizierten Domänennamen dieses Geräts konfigurieren:
Wählen Sie jetzt 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. Sie können nun Ihre konfigurierbaren Ports anzeigen:
Um jetzt einen Endpunkt zu konfigurieren, klicken Sie auf den Port, an dem Ihr analoges Gerät angeschlossen ist (in unserem Fall 0/0/0). Nachdem Sie einen Port ausgewählt haben, werden Sie aufgefordert, den Port-Typ zu konfigurieren:
In diesem Fall wählen Sie POTS aus. Sobald diese Option ausgewählt ist, 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. einen Calling Search Space. Anschließend können Sie auf Speichern klicken. Jetzt sehen Sie, dass das linke Fenster das Feld Neue DN hinzufügen für Sie ausgefüllt hat. Sie können nun eine DN mit diesem Port verknüpfen, speichern und die Konfiguration anwenden. Danach können Sie auf der Port-Konfigurationsseite den Port 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 ihn darüber zu informieren, dass der Endpunkt während des Neustarts außer Betrieb genommen werden muss. Der CUCM sendet eine einfache Bestätigung darüber. Nachdem der Neustart abgeschlossen ist, sendet CUCM eine RQNT mit dem Parameter R: L/hd. 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.
Wie Sie sehen, beginnt der Anruf-Agent, in diesem Fall CUCM, mit einer CRCX, die nur zum Gateway gelangt 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 einen einfachen 200 OK zurück, um dies zu bestätigen, und an diesem Punkt haben Sie Zwei-Wege-Medien.
Nachdem der Anruf beantwortet wurde, sendet CUCM eine weitere RQNT mit dem Parameter R: D/[0-9ABCD*#]. Dies weist das Gateway an, dem CUCM alle DTMF-Töne mitzuteilen, die bei aktivem Anruf gedrückt werden, damit dieser an das nächste Gerät weitergeleitet werden kann.
Nach Beendigung des Anrufs sendet CUCM einen MDCX an das Gateway mit M: recvonly, um den Datenträger zu terminieren, 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
Bei der Fehlerbehebung für MGCP gibt es hilfreiche Befehle und Debugging-Anweisungen, die Sie anzeigen können, um festzustellen, warum die Registrierung oder ein Anruf fehlgeschlagen ist. Sie sollten zunächst prüfen, ob Ihr MGCP-Gateway beim Anruf-Agenten registriert ist. Sie können dies mit dem Befehl show show ccm-manager oder show mgcp überprüfen:
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 | events | Pakete]
debug mgcp all (für erweitertes Debugging)
debug ccm-manager [Backhaul] | Konfiguration herunterladen | fehler | events]
debuggen voip ccapi inout
debug vpm-Signal
debug voip vtsp session
debug isdn q931
Die vorherigen Fehlerbehebungen sind ein guter Ausgangspunkt für die Behandlung von Registrierungs- und Anrufeinrichtungsproblemen.
Zugehörige Informationen
RFC 2705:
Data Tracker - Benachrichtigungsanfrage