Guida al funzionamento, alla configurazione e alla risoluzione dei problemi di MoH attraverso CUBE
Sommario
Introduzione
Questo documento descrive il funzionamento, la configurazione e le informazioni sulla risoluzione dei problemi per Multicast Music-on-Hold (MoH) con Cisco Unified Border Element (CUBE).
Sebbene il tema principale di questo documento sia la musica multicast Music-on-Hold (MoH), una parte sostanziale è dedicata alla descrizione del funzionamento generale del MoH. Queste informazioni aggiuntive aiutano a costruire una conoscenza di base per il principiante al fine di riconoscere e apprezzare meglio i problemi che sono specifici per MoH.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
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.
Sfondo
Panoramica di MoH
Il MoH viene riprodotto ogni volta che un chiamante viene messo in attesa. Il blocco della chiamata viene avviato dall'utente o dalla rete quando viene implementato un processo di servizio supplementare, ad esempio il trasferimento o il trasferimento della chiamata. Il primo viene definito blocco avviato dall'utente, blocco utente o blocco utente. Quest'ultimo viene definito blocco avviato dalla rete, blocco dalla rete o blocco dalla rete.
Di seguito viene riportata una panoramica del funzionamento del protocollo MoH con i gateway TDM (Time Division Multiplexing). L'immagine mostra i componenti e le connessioni coinvolti in uno scenario di attesa chiamata:
Per mettere una chiamata in attesa, è necessario un processo in due fasi. Questa immagine mostra le due fasi coinvolte:
Origini MoH
L'utente che mette in attesa una chiamata viene definito titolare, mentre l'utente che viene messo in attesa (e ascolta MoH) viene definito titolare. Ciascun lato decide alcuni aspetti della musica che viene riprodotta.
La fonte della musica è determinata dal titolare. La determinazione segue questa gerarchia:
- Origine musica configurata nel nome di dominio (DN)
- Origine musica configurata nel dispositivo
- Origine musica nel profilo del dispositivo (solo origine musica di attesa utente)
- Origine musica a livello globale (parametro di servizio o esempio)
Ci sono due gruppi di sorgenti musicali, chiamate user-hold e network-hold. Ogni volta che si fa riferimento a una fonte musicale, si potrebbe indicare una fonte musicale "user-hold" o "network-hold".
Endpoint MoH
Ai fini della MoH, l'endpoint sul lato CUCM è il server MoH. È importante comprenderlo perché la determinazione del codec (basata sulla configurazione del codec tra regioni) si basa su:
- Area del server MoH
- Area trunk/gateway
Si consiglia di assegnare al server MoH un'area dedicata, in modo che il codec tra tale area e tutte le altre sia g.711 (o altro codec che si desidera inviare come flusso per MoH).
Dal punto di vista di CUCM, gli endpoint coinvolti nella chiamata non sono i due telefoni, bensì:
- Il telefono IP registrato in CUCM
- Il gateway/CUBO
Pertanto, CUCM considera il trunk che punta al gateway/CUBE in questione come l'endpoint ed esamina le risorse associate per determinare come eseguire il rendering del flusso musicale.
Protocollo VoIP MoH
MoH, per definizione, è una conversazione audio unidirezionale. La modalità di segnalazione dipende dal protocollo VoIP utilizzato. Ad esempio, nel caso del SIP, la trasmissione avviene tramite l'attributo direction. In H.323, CUCM specifica 0000000 come indirizzo di rete e 0 come porta (tsapIdentifier) del server MoH nel messaggio H.245 Open Logical Channel Ack (OLCAck).
Nei flussi di chiamata che coinvolgono CUBE, CUCM non è a conoscenza del segmento di chiamata tra CUBE e il provider di servizi di telefonia Internet (ITSP). Il CUCM si occupa solo del call-leg tra il telefono IP e il trunk SIP (che porta a CUBE).
Il processo di segnalazione del MoH è simile a quello di una nuova conversazione, con ambito ridotto. Nel SIP, ad esempio, la conversazione viene eseguita nel contesto della finestra di dialogo già esistente[1]
Disabilita flusso multimediale
Il primo passaggio del processo in due passaggi sopra descritto è la disattivazione del flusso multimediale.
Nell'immagine viene mostrato come il flusso multimediale viene disabilitato in SIP:
Le implementazioni SIP variano a seconda che uno o entrambi gli attributi (?a=? e ?C=IN ?) per indicare che il flusso multimediale è disabilitato.
Nell'immagine viene mostrato come disabilitare il flusso multimediale nella H.323:
Connetti a MoH
La seconda fase del processo in due fasi sopra menzionato consiste nel collegarsi al protocollo MoH. Una volta disattivato lo streaming audio, CUCM segnala la conversazione MoH unidirezionale che fa sì che il detentore ascolti la sorgente MoH.
Nell'ambito di questo processo, CUCM tiene conto delle funzionalità multimediali del titolare e dell'elenco dei gruppi di risorse multimediali (MRGL) associato al trunk prima di determinare i parametri per il flusso. Di conseguenza, la segnalazione di questa condizione è sempre Offerta ritardata (DO)[2] (in SIP).
Il numero effettivo di transazioni INVITE varia. Ad esempio, CUCM connette il titolare a MoH con una sola transazione DO INVITE. In alternativa, viene utilizzato DO INVITE per raccogliere le capacità multimediali del titolare, e successivamente viene utilizzato EO INVITE per collegare effettivamente il titolare al MoH.
L'immagine mostra la transazione per il SIP:
L'immagine mostra la transazione per H.323:
L'immagine mostra la sequenza di messaggi di segnalazione in un ambiente di interworking (ad esempio, quando un lato di CUBE è SIP e l'altro H.323):
Utilizzo di risorse multimediali in una chiamata
Le risorse multimediali (MediaTermination Point (MTP) / Transcoder) proteggono il call-leg da CUBE a IT Service Provider (ITSP) per la maggior parte. Quando si utilizza una risorsa multimediale in una chiamata tramite CUBE, la segnalazione per MoH riguarda principalmente messaggi SCCP (Skinny Client Control Protocol) tra CUCM e la risorsa multimediale. Si noti che è la risorsa multimediale a essere messa in attesa, non il trunk CUBE. Dopo che il trascodificatore MTP/Transcoder è stato segnalato per l'ascolto di MoH (presupponendo che si tratti di SIP), CUCM invia un messaggio SIP UPDATE a CUBE. In questo modo viene aggiornato il parametro branch che identifica la nuova transazione (la conversazione MOH).
Riprendi la chiamata
Il processo di ripresa è simile al processo di blocco, con la differenza che l'ordine viene stornato:
- Il flusso audio corrente è disattivato.
- Viene inviato un altro DO-RE-INVITE per riconnettere il titolare al telefono che ha messo la chiamata in attesa.
Attributo SDP
L'attributo X-cisco-media:umoh nel protocollo SDP (Session Description Protocol) è stato introdotto per semplificare la segnalazione MoH sui trunk inter-cluster (ICT)[3]. Grazie all'interazione tra endpoint che utilizzano protocolli diversi, CUCM spesso produce segnali complessi e intermedi che non sono intuitivi. Per evitare tentativi e rendere il contesto di segnalazione esplicito, viene utilizzato un attributo SDP proprietario, denominato X-cisco-media.
Con CUCM versioni 8.5 e successive, MoH può [4] essere segnalato con questo attributo impostato su Unicast Music on Hold (UMoH) o MoH, che rimuove il ricorso a un falso valore di porta per indicare uno scenario MoH alla parte coinvolta.
MoH su CUBE
Con CUBE, il processo di base rimane lo stesso; tuttavia, è importante considerare che [5] CUBE non trascodifica MoH fino a Cisco IOS? Versione 15.3T. Ciò significa che occorre prestare attenzione ai fattori che influenzano la selezione del codec nella gamba da CUCM a CUBE in modo che non sia necessario un trascodificatore.
Considerazioni sul codec
In generale, diversi fattori influenzano il codec utilizzato nella gamba da CUCM a CUBE, ma queste considerazioni si applicano al MoH:
- MoH non può essere trascodificato.[5]
- Il MoH suona bene solo con il G.711.
MMoH
L'MoH conserva le risorse di sistema e la larghezza di banda. Il multicast consente a più utenti di utilizzare lo stesso flusso di fonti audio per fornire musica di attesa. L'MoH è desiderabile in tutte le reti aziendali in cui il risparmio della larghezza di banda è importante.
Di seguito sono riportati alcuni problemi e preoccupazioni relativi alla trasmissione di MoH da parte di CUBE tramite Internet a ITSP:
- Raggiungimento del traffico multicast - Cisco utilizza l'intervallo da 239.0.0.0 a 239.255.255.255 per la musica multicast. Questo intervallo è noto come indirizzi con ambito amministrativo. Questo blocco è considerato privato, il che significa che viene utilizzato dalle reti aziendali e non deve mai essere inoltrato al di fuori dell'azienda. I router di confine vengono in genere configurati di conseguenza.
- Multicast over VPN: per impostazione predefinita, la sicurezza IP non supporta MoH.
In questo modo CUBE supporta MoH:
- CUBE riceve i pacchetti MoH dal server MoH.
- Converte i pacchetti in pacchetti IP unicast.
- CUBE inoltra i pacchetti a ITSP.
Manipolazione attributi direzione SIP
Come descritto nella RFC 3264:
"Se la descrizione di una sessione contiene un flusso multimediale multicast elencato come solo ricezione (invio), ciò significa che i partecipanti, inclusi l'offerente e il risponditore, possono solo ricevere (inviare) su tale flusso. Questa è una differenza rispetto alla visione unicast, dove la direzionalità si riferisce al flusso dei media tra l'offerente e il risponditore. Al di là di tale chiarimento, la semantica di un flusso multicast offerto è esattamente come descritto nella RFC 2327 [1]"
Di conseguenza, quando CUCM invia un messaggio RE-INVITE con un indirizzo IP multicast, imposta l'attributo direction su recvonly; tuttavia, poiché CUBE converte i pacchetti multicast in pacchetti unicast, deve impostare l'attributo direction in modo che venga inviato solo sulla gamba con ITSP.
L'immagine mostra la logica:
Manipolazione degli indirizzi
Nel messaggio DO[6] re-INVITE inviato per connettere il chiamante ITSP all'origine MoH, CUBE invia il proprio indirizzo IP nel campo SIP SDP C=IN. Questo è un indirizzo unicast.
Questa immagine fornisce la visualizzazione end-to-end:
Streaming da Flash
Con i gateway TDM, è possibile risparmiare ulteriormente sulla larghezza di banda della WAN effettuando lo streaming della musica multicast direttamente dal gateway. Pertanto, se il server MoH si trova nella sede centrale e il gateway si trova in una filiale remota attraverso una connessione WAN, il traffico multicast che trasferisce il MoH non deve attraversare la WAN (dalla sede centrale alla filiale) e utilizzare una larghezza di banda WAN preziosa.
CUBE è un dispositivo sul lato trunk che non è in grado di inviare in streaming MoH proveniente dalla memoria flash locale o da qualsiasi interfaccia TDM analogica. È ancora possibile realizzare la larghezza di banda WAN. A tale scopo, è necessario utilizzare un altro router abilitato alla voce sulla postazione remota come origine del flusso MoH. Il router invia lo streaming di MoH dalla memoria flash. Il CUBE può quindi essere segnalato per ricevere questi pacchetti, convertirli e passarli come pacchetti unicast.
Trasmissione da un live-feed
Per eseguire lo streaming da un feed live, è necessario configurare un altro router perché CUBE non è un dispositivo di linea, come descritto nella sezione precedente.
Configura MoH
In questa sezione viene descritto come configurare MoH sugli switch con capacità CUBE, CUCM e L3.
Configura MoH su CUBE
Utilizzare questi comandi per configurare l'MoH sul CUBO:
ccm-manager music-on-hold
ip multicast-routing
Configurazione di MoH su CUCM
Per configurare l'MoH su CUCM, attenersi alla procedura seguente:
- Abilitare la funzionalità multicast sull'origine MoH, sul server MoH e sul gruppo di risorse multimediali (MRG).
- Assegnare un MRGL al trunk con il MRG configurato nel passaggio 1.
- Configurare il codec nei parametri del servizio dell'applicazione flusso vocale IP.
Configurazione della modalità MoH sugli switch con funzionalità L3
Utilizzare questi comandi per configurare l'MoH sugli switch con supporto L3:
ip routing
ip multicast-routing
Quando il protocollo MTP viene utilizzato in una chiamata
Gli MTP non supportano la musica multicast. Il detentore riceve solo aria morta[7].
Considerazioni sulle prestazioni
Tutti i pacchetti MMOH sono commutati in base al processo in Cisco IOS. Questa soluzione è ideale per installazioni di piccole dimensioni, ma ha un impatto significativo sulle prestazioni di CUBE per installazioni di grandi dimensioni.
Restrizioni
Di seguito è riportato un elenco di restrizioni relative all'uso di MoH:
- CUBE deve essere Cisco IOS versione 15.2(2)T o successive.
- MoH non è supportato su AS54xx.
- MoH non è supportato sugli ISR-G1 (serie 28xx, 38xx)
- Tenere presente i codec supportati.
Risoluzione dei problemi
Utilizzare questa sezione per risolvere i problemi relativi all'MoH.
Comandi Show e Debug
Di seguito è riportato un elenco dei comandi show e debug con il relativo significato:
- Show ccm-manager music - Conferma che CUBE sa dove ascoltare i pacchetti musicali multicast e se li riceve. .
R1#show ccm-manager music
Current active multicast sessions : 1
Multicast RTP port Packets Call Codec Incoming
Address number in/out id Interface
===================================================================
239.176.201.1 16384 956/956 237 g711ulaw Se0/1/0 - Show ip igmp members - Utilizzato per verificare se CUBE è stato aggiunto correttamente al gruppo multicast quando segnalato per l'ascolto di musica multicast.
- Questi tre comandi vengono utilizzati per controllare il codec negoziato, l'indirizzo IP e i numeri di porta degli endpoint:
Show call active voice compact
Di seguito viene riportato un esempio di output del primo comando:
Show voip rtp conn
Show sip callsR1#show call active voice compact
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
Total call-legs: 2
236 ANS T53 g711ulaw VOIP P1003 239.176.201.1:16384
237 ORG T53 g711ulaw VOIP P919789362814 200.200.200.2:17808 - Show call active voice brief: eseguire questo comando quando la chiamata è in attesa per verificare se l'rx/tx conta.
0 : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
+4190 pid:1000 Answer 1003 connected
dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 239.176.201.1:16384 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
0 : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
+4190 pid:2000 Originate 919789362814 connected
dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 200.200.200.2:17808 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a - Show perf query class "Cisco MOH Device": questo comando CLI di CUCM viene usato per verificare rapidamente se una risorsa MoH è allocata e di che tipo (unicast o multicast). Questo comando non è molto utile quando si dispone di più chiamate in attesa, poiché il conteggio cambia in modo dinamico quando le chiamate vengono messe in attesa e riprese.
admin:show perf query class "Cisco MOH Device"
==>query class :
- Perf class (Cisco MOH Device) has instances and values:
MOH_2 -> MOHHighestActiveResources = 0
MOH_2 -> MOHMulticastResourceActive = 0
MOH_2 -> MOHMulticastResourceAvailable = 250000
MOH_2 -> MOHOutOfResources = 1
MOH_2 -> MOHTotalMulticastResources = 250000
MOH_2 -> MOHTotalUnicastResources = 250
MOH_2 -> MOHUnicastResourceActive = 0
MOH_2 -> MOHUnicastResourceAvailable = 250 - Debug cm-manager music-on-hold - Questo comando viene usato per tracciare il modo in cui le gambe di chiamata vengono modificate (quando si disabilita l'audio corrente e si connette la MoH, ad esempio), nonché per verificare se CUBE si unisce al gruppo IGMP (Internet Group Management Protocol) come indicato da CUCM.
- Debug ip packet: questo comando è usato in alternativa a Wireshark per i controlli. Tuttavia, questo comando può sovraccaricare rapidamente la CPU. Utilizzarlo solo quando assolutamente necessario; disattivare la registrazione della console e non eseguirla per più di un secondo.
Scenario 1
Sintomo - Una chiamata dalla PSTN (Public Switched Telephone Network) risolve i problemi con l'audio bidirezionale. Tuttavia, quando il telefono IP mette il chiamante PSTN in attesa e quindi riprende la chiamata, si ottiene un audio unidirezionale: il telefono IP ascolta l'audio da PSTN, ma l'utente PSTN non sente il telefono IP.
In primo luogo, accertarsi che l'opzione Require SDP Inactive Exchange for Mid-Call Media Change NON sia disabilitata sul trunk SIP in questione[5]. Questo consente a CUCM di inviare un re-INVITE con a=inactive in SDP, in modo da interrompere il percorso multimediale esistente.
Quando la chiamata viene messa in attesa, CUCM non invia un nuovo INVITE con un SDP inattivo per interrompere il percorso del supporto se la casella di controllo Invia SDP invio-ricezione in invito a chiamata intermedia è abilitata per il trunk SIP[8]. Questa configurazione viene verificata solo per i dispositivi che non possono fornire un'offerta completa (invio-ricezione) dopo che la modalità multimediale è impostata su inattiva.
Di seguito sono riportate immagini che illustrano le caselle di controllo disponibili:
Scenario 2
Sintomo - C'è solo un segnale quando i chiamanti sono messi in attesa invece che in modalità MMoH.
In generale, ciò suggerisce che CUCM non ha allocato MoH.
- Utilizzare il comando show perf query class?Cisco MOH Device? il comando CUCM CLI per verificare se il conteggio MOHOOutOfResources aumenta.
- Verificare che il multicast sia abilitato nell'origine, nel server e nel gruppo MoH.
Scenario 3
Sintomo - Quando un chiamante viene messo in attesa si sente solo l'aria morta.
Accertarsi che:
- Il routing multicast è abilitato sul CUBE e su altri router nel percorso audio.
- sugli switch L3 nel percorso audio sono abilitati il routing IP e il routing multicast.
- Il valore ttl (numero di hop) è configurato sul server MoH su CUCM ed è sufficientemente grande da coprire gli hop.
- Se è necessario un transcodificatore, questo viene allocato correttamente.
- L'elenco dei codec configurati nell'applicazione IP Voice Streaming supporta il codec utilizzato per MoH.
Scenario 4
Sintomo - Una chiamata non riesce nella modalità di flusso per l'attesa e la ripresa della chiamata.
Per supportare il flusso, è necessario inviare un nuovo INVITE o un aggiornamento da IPIPGW; tuttavia, questa operazione non è attualmente supportata. Pertanto, il riversamento con chiamate DO-EO non è supportato. In caso di necessità di flusso di chiamata dal marketing, verrà presa in considerazione l'assistenza. Il bug Cisco, SIP SIP SS DO-EO: Chiamata non riuscita in modalità Flusso in attesa e ripresa per chiamata, contrassegnata come miglioramento da considerare in futuro.
Informazioni correlate
- Supporto multicast Music-on-Hold su Cisco UBE
- Domande frequenti sulla musica in attesa di CallManager
- Documentazione e supporto tecnico – Cisco Systems
[1] Può creare confusione. Come si può avere una conversazione diversa all'interno di una conversazione? In SIP, dialogo si riferisce al tag 3-tupe <To, From e Call-ID>. Questa 3-tupe rimane la stessa durante la fase di attesa.
[2] DO - Offerta ritardata.
[3] Trunk tra cluster
[4] A partire da CUCM 8.5.
[5] La trascodifica funziona per MoH in Cisco IOS versione 15.3T e successive.
[6] DO - Offerta ritardata
[7] Guida alle funzionalità e ai servizi di Cisco Unified Communications Manager, versione 8.6(1)
[8] Queste sono le impostazioni sul profilo SIP usato per configurare il trunk SIP.
Feedback