La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come configurare MGCP (Media Gateway Control Protocol) e risolvere i relativi problemi. MGCP è un protocollo Call Agent/Endpoint.
Nessun requisito specifico previsto per questo documento.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Nota: In questo documento vengono usati come punti di riferimento gli esempi di configurazione e gli output dei comandi debug e show. Le numerose funzionalità di questo documento sono chiaramente contrassegnate con la versione in cui la funzionalità è stata introdotta sia in Cisco IOS® sia in Cisco IOS-XE®.
Attributo |
Definizione |
Call Agent |
Elementi di controllo delle chiamate che svolgono il ruolo primario e forniscono funzionalità di intelligence delle chiamate centralizzate. |
Endpoint |
Gli endpoint sono i dispositivi controllati dagli agenti di chiamata. Ad esempio: FXO, FXS o un canale DS0. |
PSTN |
Rete telefonica pubblica commutata. |
Il protocollo MGCP (Media Gateway Control Protocol) è definito dalla RFC 2705. MGCP è un protocollo Call Agent/Endpoint, in cui l'endpoint è controllato da un tipo di agente di chiamata. L'intera funzionalità di controllo è controllata da un agente di chiamata che indica all'endpoint l'azione da eseguire una volta rilevato un evento. MGCP utilizza la porta TCP 2428 e la porta UDP 2427.
La porta TCP 2428 in MGCP viene utilizzata per aprire un nuovo socket con l'agente di chiamata per determinare se è possibile stabilire la connessione. Senza questo nuovo socket, i successivi messaggi MGCP non possono essere scambiati. Viene inoltre utilizzato per inviare/ricevere messaggi backhaul tra gli endpoint PRI e l'agente di chiamata a cui è registrato. Infine, la porta TCP 2428 viene utilizzata per eseguire il failover agli agenti di chiamata di backup nel caso in cui un agente di chiamata primario non risponda.
La porta UDP 2427 in MGCP viene utilizzata per i messaggi MGCP scambiati tra gli endpoint e gli agenti chiamanti.
Questo è un esempio di flusso MGCP di base. Nell'esempio è possibile vedere che il gateway riceve una nuova chiamata dalla PSTN su questo Voice Gateway (Endpoint). Il gateway notifica quindi all'agente di chiamata (CUCM) la nuova chiamata che viene ricevuta, quindi indica al gateway di creare una connessione per la nuova chiamata. Infine, il gateway invia un OK all'agente di chiamata per stabilire la chiamata.
È necessario un identificatore per ogni endpoint per consentire all'agente di chiamata di determinare l'utente a cui inviare un evento o la provenienza di un evento. Gli identificatori degli endpoint hanno due componenti principali:
Esempi:
Nel documento sono stati suddivisi i singoli componenti della configurazione in singoli passaggi.
Sul gateway analogico che si intende registrare su CUCM, questa è la configurazione minima effettivamente richiesta. È sufficiente aggiungere questa configurazione per avviare il processo di registrazione, poiché il resto della configurazione viene scaricato da 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
Per configurare il gateway MGCP in CUCM, è necessario accedere a Cisco Unified CM Administration. Una volta eseguito l'accesso, selezionare Device > Gateway:
La selezione precedente inizia dalla pagina Trova ed elenco gateway. Selezionare il pulsante Aggiungi nuovo con un segno più:
Dopo aver selezionato Aggiungi nuovo, viene richiesto di selezionare un tipo di gateway. Utilizzare questo elenco a discesa per selezionare l'hardware che si desidera registrare e selezionare Avanti per selezionare il protocollo desiderato per il dispositivo (è necessario selezionare MGCP):
Dopo aver selezionato l'hardware e il protocollo utilizzati, è necessario configurare il nome di dominio, il gruppo Cisco Unified Communications Manager e le informazioni sul modulo. Questi sono i campi principali necessari per registrare un endpoint tramite MGCP.
Il nome di dominio è composto da 1 a 2 parti. Almeno nel campo Domain Name (Nome dominio) è necessario immettere il nome host del router. In questo scenario, il nome host è:
VG320
Tuttavia, se sul gateway è configurato un nome di dominio, è necessario configurare il nome di dominio completo del dispositivo:
A questo punto è necessario premere Salva. La pagina verrà aggiornata e sarà possibile selezionare una sottounità. Dopo aver selezionato una sottounità, selezionare nuovamente Salva. È ora possibile visualizzare le porte configurabili:
Per configurare ora un endpoint, fare clic sulla porta a cui è collegata la periferica analogica (nel nostro caso, è 0/0/0). Dopo aver selezionato una porta, viene richiesto di configurare il tipo di porta:
In questo caso, selezionare POTS. Dopo aver selezionato questa opzione, è possibile immettere tutti i valori necessari per le informazioni sul dispositivo come per qualsiasi altro endpoint di Call Manager. L'unico campo obbligatorio è Pool di dispositivi, tuttavia è possibile immettere valori aggiuntivi, ad esempio Spazio di ricerca chiamate. Al termine, fare clic su Salva. A questo punto, nel riquadro di sinistra è ora visualizzato il campo Aggiungi un nuovo DN. A questo punto è possibile associare un DN a questa porta, salvare e applicare la configurazione. Al termine, nella pagina di configurazione delle porte è possibile visualizzare la porta come registrata:
In questa sezione vengono illustrate le nozioni di base di MGCP Endpoint Registration e Call Setup. Sono inclusi i messaggi dei comandi visualizzati quando il gateway interagisce con l'agente di chiamata. In questo scenario, CUCM è il nostro Call Agent.
Affinché un endpoint MGCP si registri su CUCM, il gateway apre il socket TCP 2428 su CUCM, da cui utilizza la porta UDP 2427 per inviare i messaggi di comando. Una volta aperto il socket, il gateway invia un comando RSIP al CUCM per informarlo che l'endpoint deve essere fuori servizio mentre si verifica il riavvio, e CUCM invia una semplice conferma a riguardo. Al termine del riavvio, CUCM invia un messaggio RQNT con il parametro R: L/hd. In questo modo il gateway deve notificare a CUCM un evento Off-hook.
A questo punto, il CUCM invia un'operazione AUEP (Audit Endpoint) al gateway per determinare lo stato dell'endpoint specificato. La risposta dal gateway è un ACK con funzionalità di endpoint. Al termine, l'endpoint viene registrato con CUCM. Di seguito viene riportato un esempio di output del comando debug:
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 <---
L'immagine precedente è un esempio di chiamata in uscita.
È possibile notare che l'agente di chiamata, in questo caso CUCM, inizia con un CRCX che ha ricevuto solo il gateway per stabilire la connessione per la chiamata. Il gateway risponde con un OK 200 che contiene SDP per ciò che supporta. Al termine dello scambio, CUCM invia un messaggio RQNT al gateway con il parametro S: G/rt In questo modo il gateway riprodurrà la riproduzione sul dispositivo. Dopo che l'estremità remota ha ricevuto la chiamata e l'ha ripresa, CUCM invia un MDCX con SDP al gateway per comunicargli le informazioni multimediali per il dispositivo più lontano. Il gateway restituisce un semplice 200 OK per confermare questa condizione e a questo punto si dispone di un supporto bidirezionale.
Dopo aver risposto alla chiamata, CUCM invia un altro RQNT con il parametro R: D/[0-9ABCD*#]. In questo modo il gateway informa CUCM di qualsiasi DTMF premuto mentre la chiamata è attiva in modo che possa essere inoltrato al dispositivo successivo.
Al termine della chiamata, CUCM invia un MDCX al gateway con il comando M: recvonly per terminare il supporto, seguito da un DLCX per interrompere la chiamata. Di seguito viene riportato un esempio di output del comando debug:
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 <---
Quando si risolvono i problemi relativi a MGCP, è possibile visualizzare alcuni utili comandi show e debug per determinare il motivo per cui la registrazione o una chiamata non è riuscita. È consigliabile verificare se il gateway MGCP è registrato per l'agente di chiamata. È possibile controllare questa condizione tramite il comando show show ccm-manager o 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
Questi comandi sono stati abbreviati per contenere solo l'output pertinente. Per ulteriori informazioni, vedere i seguenti output del comando show:
show mgcp
show mgcp endpoint
mostra connessione mgcp
show ccm-manager
show voice port summary
show isdn status
show controller [t1/e1] x/x/x
show call active voice brief
mostra riepilogo chiamate vocali
mostra stato chiamata vocale
Se i comandi show precedenti sono estratti, è possibile eseguire questi debug sul dispositivo per determinare ulteriormente il motivo per cui la chiamata non è riuscita:
debug mgcp [endpoint] Errore | | eventi | pacchetti]
debug mgcp all (per il debug avanzato)
debug ccm-manager [backhaul] | config-download Errore | | eventi]
debug voip ccapi inout
debug segnale vpm
sessione debug voip vtsp
debug isdn q931
I debug precedenti rappresentano un ottimo punto di partenza per la risoluzione dei problemi di registrazione e configurazione delle chiamate.
RFC 2705:
Revisione | Data di pubblicazione | Commenti |
---|---|---|
3.0 |
15-Jul-2022 |
Certificazione |
1.0 |
14-Aug-2019 |
Versione iniziale |