Guide d'utilisation, de configuration et de dépannage de la technologie MoH via CUBE
Contenu
Introduction
Ce document décrit le fonctionnement, la configuration et les informations de dépannage pour la musique d'attente multidiffusion (MoH) via Cisco Unified Border Element (CUBE).
Bien que le présent document soit axé sur la multidiffusion de musique d'attente (MoH), une partie importante est consacrée à la description du fonctionnement du MoH en général. Ces informations supplémentaires aident à créer une base de connaissances pour le débutant afin de mieux reconnaître et apprécier les problèmes spécifiques à la MoH.
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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. If your network is live, make sure that you understand the potential impact of any command.
Fond
Présentation du Ministère de la santé
La musique d'attente est diffusée chaque fois qu'un appelant est mis en attente. La mise en attente d'appel est initiée par l'utilisateur ou par le réseau lorsqu'un processus de service supplémentaire est mis en oeuvre, tel que le renvoi ou le transfert d'appel. Le premier est appelé attente initiée par l'utilisateur, attente utilisateur ou attente utilisateur. Ce dernier est appelé mise en attente initiée par le réseau, mise en attente du réseau ou mise en attente du réseau.
Voici un aperçu de la façon dont MoH fonctionne avec les passerelles TDM (Time Division Multiplexing). Cette image illustre les composants et les connexions impliqués dans un scénario de mise en attente d'appel :
Pour mettre un appel en attente, un processus en deux étapes est nécessaire. Cette image illustre les deux étapes suivantes :
Sources de musique d'attente
L'utilisateur qui met un appel en attente est appelé le titulaire, et l'utilisateur qui est mis en attente (et entend la musique d'attente) est appelé le titulaire. Chaque partie décide de certains aspects de la musique jouée.
La source musicale est déterminée par le titulaire. La détermination suit cette hiérarchie :
- Source de musique configurée sur le nom de domaine (DN)
- Source de musique configurée sur le périphérique
- Source de musique sur le profil de périphérique (source de musique d'attente utilisateur uniquement)
- Source de musique au niveau global (paramètre de service, ou exemple)
Il existe deux ensembles de sources musicales, appelés attente utilisateur et mise en attente réseau. Chaque fois que vous faites référence à une source musicale, cela peut signifier une source musicale d'attente utilisateur ou réseau.
Terminaux MoH
Pour les besoins de la musique d'attente, le point de terminaison côté CUCM est le serveur de musique d'attente. Il est important de le comprendre car la détermination du codec (basée sur la configuration du codec inter-régions) repose sur :
- Région du serveur de musique d'attente
- Région de liaison/passerelle
La recommandation générale est d'attribuer au serveur de musique d'attente une région dédiée, de sorte que le codec inter-région entre cette région et toutes les autres régions soit g.711 (ou tout autre codec que vous voulez diffuser pour musique d'attente).
Du point de vue de CUCM, les terminaux impliqués dans l'appel ne sont pas les deux téléphones, mais plutôt :
- Téléphone IP enregistré auprès de CUCM
- Passerelle/CUBE
Ainsi, CUCM traite la liaison qui pointe vers la passerelle/CUBE en question comme point de terminaison, et examine les ressources qui lui sont associées afin de déterminer comment rendre le flux de musique.
Protocole VoIP MoH
La musique d'attente, par définition, est une conversation audio unidirectionnelle. La façon dont elle est signalée dépend du protocole VoIP utilisé. Par exemple, sur SIP, ceci est transmis via l'attribut direction. Sur H.323, CUCM spécifie 0000000 comme adresse réseau et 0 comme port (tsapIdentifier) du serveur de musique d'attente dans le message OLCAck (Open Logical Channel Ack) H.245.
Dans les flux d'appels impliquant CUBE, CUCM ne connaît pas le segment d'appel entre CUBE et le fournisseur de services de téléphonie Internet (ITSP). Le CUCM ne concerne que le segment d'appel entre le téléphone IP et la ligne principale SIP (menant à CUBE).
Le processus de signalisation pour la musique d'attente est similaire à la signalisation pour une nouvelle conversation, avec une portée réduite. Dans SIP, par exemple, la conversation se déroule dans le contexte de la boîte de dialogue qui existe déjà .[1]
Désactiver le flux multimédia
La première étape du processus en deux étapes précédemment mentionné consiste à désactiver le flux multimédia.
Cette image montre comment le flux multimédia est désactivé dans SIP :
Les mises en oeuvre SIP varient selon que l'un ou les deux attributs (?a=? et ?C=IN ?) sont utilisés afin d'indiquer que le flux multimédia est désactivé.
Cette image montre comment le flux multimédia est désactivé dans le H.323 :
Se connecter à la musique d'attente
La deuxième étape du processus en deux étapes mentionné précédemment consiste à se connecter à la musique d'attente. Une fois le flux audio désactivé, CUCM signale la conversation de musique d'attente unidirectionnelle qui fait que le contenu écoute la source de musique d'attente.
Dans le cadre de ce processus, CUCM prend en compte les capacités multimédias du conteneur et de la liste MRGL (Media Resource Group List) associée à la liaison avant de déterminer les paramètres de diffusion en continu. Par conséquent, la signalisation pour cela est toujours Offre différée (DO)[2] (dans SIP).
Le nombre réel de transactions INVITE varie. Par exemple, CUCM connecte le conteneur à MoH avec une seule transaction DO INVITE. Alternativement, le DO INVITE est utilisé afin de recueillir les capacités médiatiques du détenteur, et un EO INVITE ultérieur est utilisé afin de connecter effectivement le détenteur à la musique d'attente.
Cette image illustre la transaction pour SIP :
Cette image illustre la transaction pour H.323 :
Cette image illustre la séquence de messages de signalisation dans un environnement d'interconnexion (lorsqu'un côté de CUBE est SIP et l'autre côté H.323, par exemple) :
Lorsque des ressources multimédias sont utilisées dans un appel
Les ressources multimédias (MediaTermination Point (MTP) / Transcoders) protègent la branche d'appel CUBE-IT (ITSP) pour la plupart. Lorsqu'une ressource multimédia est utilisée dans un appel via CUBE, la signalisation de la musique d'attente implique principalement des messages SCCP (Skinny Client Control Protocol) entre CUCM et la ressource multimédia. Notez qu'il s'agit de la ressource multimédia mise en attente et non de la liaison CUBE. Une fois que le MTP/Transcoder est signalé pour écouter la musique d'attente (en supposant SIP), CUCM envoie un message SIP UPDATE à CUBE. Ceci met à jour le paramètre Branch, qui identifie la nouvelle transaction (la conversation MOH).
Reprendre l'appel
Le processus de reprise est similaire au processus de mise en attente, sauf que la commande est annulée :
- Le flux audio actuel est désactivé.
- Un autre DO re-INVITE est envoyé afin de reconnecter le blocage au téléphone qui a mis l'appel en attente.
Attribut SDP
L'attribut X-cisco-media:umoh du protocole SDP (Session Description Protocol) a été introduit afin de simplifier la signalisation de musique d'attente sur les liaisons interclusters (ICTs)[3]. Grâce à l’interopérabilité entre les points d’extrémité qui utilisent différents protocoles, CUCM effectue souvent des signaux maladroits et intermédiaires qui ne sont pas intuitifs. Afin d'éviter les conjectures et rendre la signalisation contextuelle explicite, un attribut SDP propriétaire, nommé X-cisco-media, est utilisé.
Avec CUCM versions 8.5 et ultérieures, la musique d'attente peut [4] être signalée avec cet attribut défini sur Unicast Music on Hold (UMoH) ou MMoH, ce qui supprime la dépendance sur une fausse valeur de port pour indiquer un scénario de musique d'attente à la partie détenue.
MoH sur CUBE
Avec CUBE, le processus de base reste le même ; cependant, il est important de considérer que [5] CUBE ne transcode pas la musique d'attente avant Cisco IOS ? Version 15.3T Cela signifie que vous devez être prudent avec les facteurs qui influencent la sélection du codec dans la jambe CUCM-CUBE afin qu'un transcodeur ne soit pas nécessaire.
Considérations relatives aux codecs
En général, plusieurs facteurs affectent le codec utilisé dans la branche CUCM-CUBE, mais ces considérations s'appliquent à la musique d'attente :
- La musique d'attente ne peut pas être transcodée.[5]
- La musique d'attente n'est bonne qu'avec G.711.
MoH
La bande passante et les ressources du système sont conservées. La multidiffusion permet à plusieurs utilisateurs d'utiliser le même flux source audio afin de fournir de la musique d'attente. Il est souhaitable d'utiliser la technologie MoH dans tout réseau d'entreprise où les économies de bande passante sont importantes.
Voici quelques préoccupations et problèmes lorsque CUBE transmet MMoH sur Internet à ITSP :
- Portée du trafic de multidiffusion - Cisco utilise la plage 239.0.0.0 à 239.255.255.255 pour la musique de multidiffusion. Cette plage est connue sous le nom d'adresses administrativement étendues. Ce bloc est considéré comme privé, ce qui signifie qu'il est utilisé par les réseaux d'entreprise et ne doit jamais être transféré en dehors de l'entreprise. Les routeurs de périphérie sont généralement configurés en conséquence.
- Multidiffusion sur VPN - Par défaut, la sécurité IP ne prend pas en charge la technologie MMoH.
Voici comment CUBE prend en charge la technologie MMoH :
- CUBE reçoit les paquets MMoH du serveur de musique d'attente.
- Il convertit les paquets en paquets IP de monodiffusion.
- CUBE transfère les paquets à ITSP.
Manipulation d'attribut de direction SIP
Comme décrit dans la RFC 3264 :
« Si une description de session contient un flux multimédia multidiffusion qui est répertorié en tant que réception (envoi) uniquement, cela signifie que les participants, y compris l'offrant et le répondeur, ne peuvent recevoir (envoyer) que sur ce flux. Ceci diffère de la vue de monodiffusion, où la directionnalité fait référence au flux de média entre l'offrant et le répondeur. Au-delà de cette clarification, la sémantique d'un flux multidiffusion offert est exactement celle décrite dans la RFC 2327 [1]"
Par conséquent, lorsque CUCM envoie une invitation à nouveau avec une adresse IP de multidiffusion, il définit l'attribut de direction sur recvonly ; toutefois, étant donné que CUBE convertit les paquets de multidiffusion en paquets de monodiffusion, il doit définir l'attribut de direction sur sendonly sur la jambe avec ITSP.
Cette image illustre la logique :
Manipulation d’adresses
Dans le DO[6] re-INVITE envoyé afin de connecter l'appelant ITSP à la source de musique d'attente, CUBE envoie sa propre adresse IP dans le champ SIP SDP C=IN. Il s’agit d’une adresse de monodiffusion.
Cette image fournit la vue de bout en bout :
Flux à partir d'une mémoire Flash
Avec les passerelles TDM, des économies supplémentaires de bande passante WAN sont réalisées en diffusant la musique multidiffusion directement depuis la passerelle. Ainsi, si le serveur de musique d'attente se trouve au siège et que la passerelle se trouve dans une succursale distante via une connexion WAN, le trafic de multidiffusion qui transporte la musique d'attente n'a pas à traverser le WAN (du siège à la succursale) et utilise une bande passante WAN précieuse.
CUBE est un périphérique côté liaison qui n'est pas capable de transmettre de la musique d'attente en continu provenant de la mémoire flash locale ou d'une interface TDM analogique. Il est toujours possible de réaliser la bande passante WAN. Pour ce faire, utilisez un autre routeur vocal dans la succursale distante comme source du flux MMoH. Ce routeur diffuse de la musique d'attente à partir de la mémoire Flash. Le CUBE peut ensuite être signalé afin de recevoir ces paquets, de les convertir et de les transmettre en paquets de monodiffusion.
Flux à partir d'un flux en direct
Pour diffuser à partir d'un flux en direct, un autre routeur doit être configuré car CUBE n'est pas un périphérique côté ligne, comme indiqué dans la section précédente.
Configurer la multifonction
Cette section décrit comment configurer la technologie MMoH sur les commutateurs CUBE, CUCM et compatibles L3.
Configurer la multifonction sur CUBE
Utilisez ces commandes afin de configurer MMoH sur CUBE :
ccm-manager music-on-hold
ip multicast-routing
Configuration de la multifonction sur CUCM
Suivez les étapes suivantes afin de configurer MMoH sur CUCM :
- Activez la fonctionnalité de multidiffusion sur la source de musique d'attente, le serveur de musique d'attente et le groupe de ressources multimédias (MRG).
- Attribuez un MRGL à la liaison avec le MRG configuré à l'étape 1.
- Configurez le codec dans les paramètres du service d'application de diffusion vocale en continu IP.
Configurer la multidisponibilité sur les commutateurs compatibles L3
Utilisez ces commandes afin de configurer la technologie MMoH sur les commutateurs compatibles L3 :
ip routing
ip multicast-routing
Quand le protocole MTP est utilisé dans un appel
Les MTP ne prennent pas en charge la musique multidiffusion. Le détenteur ne reçoit que l'air mort.[7]
Considérations relatives aux performances
Tous les paquets MMOH sont commutés dans Cisco IOS. Cela convient pour les déploiements de petite envergure, mais a un impact significatif sur les performances de CUBE pour les grandes installations.
Restrictions
Voici une liste de restrictions avec l'utilisation de MoH :
- CUBE doit être installé sur Cisco IOS Version 15.2(2)T ou ultérieure.
- MoH n'est pas pris en charge sur AS54xx.
- La technologie MMoH n'est pas prise en charge sur les routeurs ISR-G1 (gamme 28xx, 38xx)
- Soyez conscient des codecs pris en charge.
Dépannage
Utilisez cette section afin de dépanner le MoH.
Commandes Show and Debug
Voici une liste des commandes show et debug, ainsi que leurs significations :
- Show ccm-manager music - Permet de confirmer que CUBE sait où écouter les paquets de musique multidiffusion, et aussi s'il les reçoit. .
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 member - Utilisé afin de vérifier si CUBE a réussi à rejoindre le groupe de multidiffusion lorsqu'il est signalé pour écouter de la musique multidiffusion.
- Ces trois commandes sont utilisées afin de vérifier le codec négocié, l'adresse IP et les numéros de port des points d'extrémité :
Show call active voice compact
Voici un exemple de sortie de la première commande :
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 - Émettez cette commande lorsque l'appel est en attente afin de vérifier si le nombre rx/tx augmente.
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 » - Cette commande CLI CUCM est utilisée afin de vérifier rapidement si une ressource MoH est allouée et quel type (monodiffusion ou multidiffusion). Cette commande n'est pas très utile lorsque vous avez plusieurs appels en attente, car le nombre change dynamiquement lorsque les appels sont mis en attente et repris.
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 ccm-manager music-on-hold - Cette commande est utilisée afin de tracer la façon dont les branches d'appel sont modifiées (lorsque vous désactivez l'audio actuel et connectez la musique d'attente, par exemple), et vérifier si CUBE rejoint le groupe IGMP (Internet Group Management Protocol) comme indiqué par CUCM.
- Debug ip packet - Cette commande est utilisée comme alternative à Wireshark pour les vérifications. Cependant, cette commande peut rapidement submerger le processeur. Ne l'utiliser que lorsque cela est absolument nécessaire ; désactivez la journalisation de console et ne l'exécutez pas plus d'une seconde.
Scénario 1
Symptôme : un appel du réseau téléphonique public commuté (RTPC) s'effectue correctement avec le son bidirectionnel. Cependant, lorsque le téléphone IP met l'appelant RTPC en attente, puis reprend l'appel, les résultats audio unidirectionnels sont les suivants : le téléphone IP entend le son du RTPC, mais l'utilisateur du RTPC ne peut pas entendre le téléphone IP.
Tout d'abord, assurez-vous que Require SDP Inactive Exchange for Mid-Call Media Change n'est PAS désactivé sur la ligne principale SIP en question[5]. C'est ce qui permet à CUCM d'envoyer une invitation à nouveau avec a=inactive dans SDP, afin de rompre le chemin d'accès au support qui existe.
Lorsque l'appel est mis en attente, CUCM n'envoie pas de message de nouvelle invitation avec un SDP inactif afin de rompre le chemin du support si la case Envoyer le SDP d'envoi-réception en cours d'appel INVITE est activée pour la ligne principale SIP [8]. Cette configuration n'est vérifiée que pour les périphériques qui ne peuvent pas fournir une offre complète (send-recv) après que le mode média a été défini sur Inactif.
Voici des images illustrant les cases à cocher disponibles :
Scénario 2
Symptôme - Il n'y a qu'une tonalité lorsque les appelants sont mis en attente au lieu de MoH.
En règle générale, cela donne à penser que CUCM n'a pas affecté de MoH.
- Utiliser la classe de requête show perf ?Cisco MOH Device ? Commande CLI CUCM afin de vérifier si le nombre MOHOutOfResources s'incrémente.
- Assurez-vous que la multidiffusion est activée sur la source, le serveur et le groupe MoH.
Scénario 3
Symptôme : seul l'air mort est entendu lorsqu'un appelant est mis en attente.
Vérifiez les points suivants :
- Le routage multidiffusion est activé sur le CUBE et sur les autres routeurs du chemin audio.
- Le routage IP et le routage multidiffusion sont activés sur les commutateurs L3 du chemin audio.
- Le ttl (nombre de sauts) est configuré sur le serveur de musique d'attente sur CUCM et est assez grand pour couvrir les sauts.
- Si un transcodeur est requis, il est attribué avec succès.
- La liste des codecs configurés sur l'application IP Voice Streaming prend en charge le codec utilisé pour la musique d'attente.
Scénario 4
Symptôme - Un appel échoue en mode de flux pour la mise en attente et la reprise des appels.
Pour prendre en charge le flux de contournement, vous devez envoyer un message de nouvelle invitation ou une mise à jour de IPIPGW ; toutefois, ce n'est pas le cas actuellement. Par conséquent, l'acheminement des appels DO-EO n'est pas pris en charge. S'il y a une telle exigence de flux d'appels du marketing, un soutien sera pris en considération. Le bogue Cisco, SIP SIP SS DO-EO : Échec de l'appel en mode de contournement pour la mise en attente et la reprise de l'appel, est marqué comme une amélioration à envisager dans le futur.
Informations connexes
- Prise en charge de la musique d'attente multidiffusion sur Cisco UBE
- CallManager Music on Hold - Forum aux questions
- Support et documentation techniques - Cisco Systems
[1] Cela peut être déroutant : comment pouvez-vous avoir une autre conversation dans une boîte de dialogue ? Eh bien, dans SIP, la boîte de dialogue fait référence à la balise 3-tupe <To tag, From tag et Call-ID>. Ce 3-tupe reste le même pendant la phase de rétention.
[2] DO - Offre différée.
[3] Liaison inter-cluster
[4] À partir de CUCM 8.5.
[5] Le transcodage fonctionne pour MoH dans Cisco IOS versions 15.3T et ultérieures.
[6] DO - Offre différée
[7] Guide des fonctionnalités et des services de Cisco Unified Communications Manager, version 8.6(1)
[8] Il s'agit des paramètres du profil SIP utilisés pour configurer la ligne principale SIP.
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)