Configuration et dépannage des passerelles MGCP

Introduction

Ce document décrit comment configurer et dépanner le protocole MGCP (Media Gateway Control Protocol). MGCP est un protocole Call Agent/Endpoint.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

• Cisco Unified Communications Manager 11.5
• VG320

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

Remarque : ce document utilise des exemples de configuration ainsi que des sorties de commande debug et show comme points de référence. Les nombreuses fonctionnalités de ce document sont clairement identifiées par la version de la fonctionnalité introduite dans Cisco IOS® et Cisco IOS® XE.

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 contrôlés par les agents d'appel. Par exemple : 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. MGCP est un protocole d'agent d'appel/point de terminaison, dans lequel le point de terminaison est contrôlé par un agent d'appel d'un certain type. L'ensemble des informations de contrôle est contrôlé 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. Vous pouvez voir dans l'exemple que la passerelle reçoit un nouvel appel du RTPC sur cette passerelle vocale (point de terminaison). Le modem routeur notifie alors l'agent d'appel (CUCM) de ce nouvel appel qui est reçu, l'agent d'appel demande alors 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 terminaux 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é chacun des composants de configuration en étapes individuelles.

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 réellement requise. Il vous suffit d'ajouter cette configuration pour démarrer le processus d'enregistrement, car le reste de la configuration est ensuite téléchargé à 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

Afin de configurer la passerelle MGCP dans CUCM, vous devez vous connecter à l'administration de Cisco Unified CM. Une fois connecté, accédez à Device > Gateway :

La sélection précédente vous lance à la page Find and List Gateway. Sur ce, vous voulez sélectionner le bouton Add New avec un signe plus :

Une fois que vous avez sélectionné Add New, vous êtes invité à choisir un type de passerelle. Utilisez cette liste déroulante afin de 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) :

Maintenant 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.

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 mon scénario, le nom d'hôte est :

VG320

Toutefois, si un nom de domaine est configuré sur la passerelle, vous devez configurer le nom de domaine complet de ce périphérique :

Sélectionnez Enregistrer. 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, choisissez à nouveau Enregistrer. Vous pouvez maintenant voir vos ports configurables :

Afin de configurer un terminal maintenant, cliquez sur le port dans lequel vous avez votre périphérique analogique branché (Dans notre cas, il est 0/0/0). Une fois que vous avez sélectionné un port, vous êtes invité à configurer le type de port :

Dans ce cas, vous sélectionnez POTS. Une fois cette option sélectionnée, vous pouvez entrer toutes les valeurs nécessaires pour les informations sur le 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 qu'un espace de recherche d'appels. Une fois que vous avez fait cela, vous pouvez alors cliquer sur Enregistrer. À ce stade, vous voyez que le volet de gauche a renseigné le champ Ajouter un nouveau DN pour vous. Vous pouvez maintenant associer un DN à ce port, enregistrer et appliquer la configuration. Une fois que cela est fait, de retour à la page de configuration du port, vous pouvez maintenant voir le port comme enregistré :

Enregistrement des terminaux et configuration des appels

Dans cette section, vous aborderez les notions de base de l'enregistrement des terminaux MGCP et de la configuration des appels. Cela inclut les messages de commandes 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 l'informer que le terminal doit être mis hors service pendant le redémarrage, et 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 a reçu uniquement sur la passerelle 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. À ce stade, vous disposez d'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 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 quelques commandes show et débogages utiles afin de déterminer pourquoi l'enregistrement ou un appel a échoué. Pour commencer, nous vous conseillons de vérifier si votre passerelle MGCP est inscrite auprès de l'agent d'appel. Vous pouvez vérifier ceci via 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, vous pouvez consulter ces résultats de la commande show :

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 résoudre les problèmes d'enregistrement et de configuration des appels.

Informations connexes

RFC 2705 :

Data Tracker - Demande de notification