Configuration et dépannage des passerelles MGCP
Table des matières
Introduction
Ce document décrit comment configurer et dépanner le Media Gateway Control Protocol (MGCP) ; MGCP est un protocole Call Agent/Endpoint.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
- VG320
- Cisco Unified Communications Manager 11.5
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Définitions communes
| Attribut |
Définition |
| Agent D'Appel |
Les éléments de contrôle d'appel qui jouent le rôle principal et fournissent une intelligence d'appel centralisée. |
| Terminaux |
Les terminaux sont les périphériques que les agents d'appel contrôlent, tels que : FXO, FXS ou un canal DS0. |
| RTPC |
Réseau téléphonique public commuté. |
Principes fondamentaux de MGCP
Le protocole MGCP (Media Gateway Control Protocol) est défini par la RFC 2705. Le protocole MGCP est un protocole Call Agent/Endpoint dans lequel le terminal est contrôlé par un agent d'appel d'un certain type. L'ensemble des informations de contrôle est géré par un Call Agent qui indique au terminal l'action à entreprendre une fois qu'un événement est détecté. MGCP utilise les ports TCP 2428 et UDP 2427.
Le port TCP 2428 dans MGCP est utilisé pour ouvrir un nouveau socket avec l'agent d'appel afin de déterminer si la connexion peut être établie. Sans ce nouveau socket, les messages MGCP suivants ne peuvent pas être échangés. Il est également utilisé pour envoyer/recevoir des messages de liaison entre les terminaux PRI et l'agent d'appel auquel il est enregistré. Enfin, le port TCP 2428 est utilisé pour effectuer un basculement sur incident afin de sauvegarder les agents d'appel dans le cas où un agent d'appel principal ne répond pas.
Le port UDP 2427 de MGCP est utilisé pour les messages MGCP échangés entre les terminaux et les agents d'appel.
Débit De Base
Voici un exemple de flux MGCP de base. Dans cet exemple, la passerelle reçoit un nouvel appel du RTPC sur cette passerelle vocale (point de terminaison). Le modem routeur informe l'agent d'appel (CUCM) de ce nouvel appel qui est reçu, l'agent d'appel demande au modem routeur de créer une connexion pour ce nouvel appel. Enfin, le modem routeur renvoie un message OK à l'agent d'appel pour établir l'appel.
Identificateurs de terminal
Un identificateur est nécessaire par point d'extrémité pour que l'agent d'appel puisse déterminer qui doit envoyer un événement ou d'où provient un événement. Les identificateurs de point de terminaison ont deux composants principaux :
- Nom local dans ce modem routeur (non sensible à la casse).
- Nom de domaine de la passerelle qui gère le point d'extrémité (sensible à la casse).
Exemples:
- AALN/S1/SU0/0@AV-VG200-2.cisco.com
- S0/SU0/DS1-0@AV-VG200-1
Configuration de base de MGCP
Ce document a divisé chaque composant de configuration en différentes étapes.
Configuration CLI de passerelle
Sur la passerelle analogique que vous prévoyez d'enregistrer auprès de CUCM, il s'agit de la configuration minimale requise. Il vous suffit d'ajouter cette configuration pour démarrer le processus d'enregistrement, car la configuration restante est téléchargée à partir de CUCM :
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
Configuration CUCM
Étape 1. Pour configurer la passerelle MGCP dans CUCM, vous devez vous connecter à Cisco Unified CM Administration. Une fois connecté, accédez à Device > Gateway :
Étape 2. La sélection précédente vous place sur la page Find and List Gateway. Sur cette page, sélectionnez le bouton Ajouter nouveau avec le signe "+" (plus) :
Étape 3. Après avoir sélectionné Add New, vous êtes invité à choisir un type de passerelle. Utilisez la liste déroulante pour choisir le matériel que vous prévoyez d'enregistrer, et sélectionnez Next pour choisir le protocole que vous voulez pour ce périphérique (vous devez sélectionner MGCP) :
Étape 4. Une fois que vous avez sélectionné le matériel et le protocole utilisés, vous devez configurer le nom de domaine, le groupe Cisco Unified Communications Manager et les informations sur le module. Il s'agit des principaux champs requis pour enregistrer un terminal via MGCP.
Étape 5. Le nom de domaine se compose de 1 à 2 parties. Au minimum, dans le champ Domain Name, vous devez entrer le Host Name du routeur. Dans ce scénario, le nom d'hôte est :
VG320. Cependant, si vous avez un nom de domaine configuré sur la passerelle, vous devez configurer le nom de domaine complet de ce périphérique :
Étape 6. Sélectionnez Sauvegarder. Cette opération met à jour la page et vous permet de sélectionner un sous-ensemble. Une fois que vous avez sélectionné un sous-ensemble, sélectionnez à nouveau Enregistrer. Vous pouvez maintenant voir vos ports configurables :
Étape 7. Pour configurer un terminal, cliquez sur le port auquel votre périphérique analogique est connecté (dans ce scénario, il s’agit de 0/0/0). Une fois que vous avez sélectionné un port, vous êtes invité à configurer le type de port :
Étape 8. Dans ce cas, sélectionnez POTS. Une fois cette option sélectionnée, vous pouvez entrer toutes les valeurs nécessaires pour les informations relatives au périphérique, comme vous le feriez pour n'importe quel autre terminal Call Manager. Le seul champ obligatoire est Pool de périphériques. Toutefois, vous pouvez saisir des valeurs supplémentaires, telles que Espace de recherche d'appels. Une fois terminé, cliquez sur Save.
Étape 9. À ce stade, le volet de gauche a renseigné le champ Add a New DN. Vous pouvez maintenant associer un DN à ce port, enregistrer et appliquer la configuration. Une fois cette opération terminée, revenez à la page de configuration du port pour voir que le port est enregistré :
Enregistrement des terminaux et configuration des appels
Cette section traite des notions de base sur l'enregistrement des terminaux MGCP et la configuration des appels. Cela inclut les messages de commande affichés lorsque la passerelle interagit avec l'agent d'appel. Dans ce scénario, CUCM est notre agent d'appel.
Enregistrement des terminaux MGCP
Pour qu'un terminal MGCP s'enregistre auprès de CUCM, le modem routeur ouvre le socket TCP 2428 vers CUCM. À partir de là, il utilise le port UDP 2427 pour envoyer des messages de commande. Une fois le socket ouvert, le modem routeur envoie une commande RSIP au CUCM pour informer le terminal qu'il doit être mis hors service pendant le redémarrage. Le CUCM envoie un simple accusé de réception à ce sujet. Une fois le redémarrage terminé, CUCM envoie un RQNT avec le paramètre R: L/hd. Cela signifie que le modem routeur doit informer CUCM d'un événement de décrochage.
À ce stade, le CUCM envoie un point de terminaison d'audit (AUEP) à la passerelle pour déterminer l'état du point de terminaison donné. La réponse du modem routeur est un accusé de réception avec les fonctionnalités des terminaux. Une fois cette opération terminée, le terminal est enregistré auprès du CUCM. Voici un exemple de sortie de débogage :
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 <---
Configuration d'appel MGCP
L'image précédente est un exemple d'appel sortant.
Vous pouvez voir que votre Call Agent, dans ce cas CUCM, commence par un CRCX qui n'a reçu que le modem routeur pour établir la connexion pour l'appel. Le modem routeur répond par un 200 OK contenant le protocole SDP pour ce qu'il prend en charge. Une fois cet échange effectué, le CUCM envoie un message RQNT au modem routeur avec le paramètre S: G/rt. Cela indique au modem routeur de lire la sonnerie sur le périphérique. Une fois que l'extrémité distante reçoit l'appel et décroche, CUCM envoie un message MDCX avec SDP au modem routeur pour lui faire connaître les informations sur le support du périphérique distant. Le modem routeur renvoie un simple message 200 OK pour accuser réception de ce message et, à ce stade, vous avez établi un support bidirectionnel.
Maintenant que l'appel a obtenu une réponse, CUCM envoie un autre RQNT avec le paramètre R: D/[0-9ABCD*#]. Cela indique au modem routeur d'informer CUCM de toute DTMF qui est pressée pendant que l'appel est actif, afin qu'il puisse être relayé vers le périphérique suivant.
Une fois l'appel terminé, CUCM envoie un message MDCX au modem routeur avec M: recvonly pour terminer le support, suivi d'un DLCX pour déconnecter l'appel. Voici un exemple de sortie de débogage :
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 <---
Dépannage de MGCP
Lorsque vous dépannez MGCP, vous pouvez afficher certaines commandes show et débogages utiles pour déterminer pourquoi l'enregistrement ou un appel a échoué. Pour commencer, vérifiez si votre passerelle MGCP est enregistrée auprès de l'agent d'appel. Vous pouvez vérifier en exécutant la commande show show ccm-manager ou show mgcp :
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
Ces commandes ont été raccourcies pour ne contenir que le résultat pertinent. Pour plus d'informations, reportez-vous à la section suivante :
- show mgcp
- show mgcp endpoint
- show mgcp connection
- show ccm-manager
- show voice port summary
- show isdn status
- show controller [t1/e1] x/x/x
- show call active voice brief
- show voice call summary
- show voice call status
Si les commandes show précédentes sont récupérées, vous pouvez exécuter ces débogages sur le périphérique pour déterminer plus précisément pourquoi votre appel a échoué :
- debug mgcp [endpoint] | erreur | événements | paquets]
- debug mgcp all (pour le débogage avancé)
- debug ccm-manager [backhaul] | config-download | erreur | événements]
- debug voip ccapi inout
- debug vpm signal
- debug voip vtsp session
- debug isdn q931
Les débogages précédents constituent un excellent point de départ pour le dépannage des problèmes d'enregistrement et de configuration des appels.
Informations connexes
- RFC 2705 : Suivi des données - Demande de notification
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
5.0 |
02-Jul-2026
|
Mise à jour de l'orthographe, de l'espacement et du texte de remplacement. |
4.0 |
29-Aug-2023
|
Mise à jour des PII, du SEO, des exigences de marque et du formatage. |
3.0 |
15-Jul-2022
|
Recertification |
1.0 |
14-Aug-2019
|
Première publication |
Commentaires