Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Fond

Présentation du Ministère de la santé

Désactiver le flux multimédia

Se connecter à la musique d'attente

Lorsque des ressources multimédias sont utilisées dans un appel

Reprendre l'appel

Attribut SDP

MoH sur CUBE

Considérations relatives aux codecs

MoH

Manipulation d'attribut de direction SIP

Manipulation d’adresses

Flux à partir d'une mémoire Flash

Flux à partir d'un flux en direct

Configurer la multifonction

Quand le protocole MTP est utilisé dans un appel

Considérations relatives aux performances

Restrictions

Dépannage

Commandes Show and Debug

Scénario 1

Scénario 2

Scénario 3

Scénario 4

Informations connexes

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.

Note: Bien que les principes soient identiques, Cisco Unified Border Element-Service Provider Edition (CUBE-SP) ne relève pas du champ d'application de ce document, pas plus que l'utilisation de CUBE dans les environnements qui n'impliquent pas Cisco Unified Communications Manager (CUCM).

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

Note: À l'exception de quelques scénarios illustrés pour H.323, la signalisation SIP (Session Initiation Protocol) est utilisée dans la plupart de ce document.

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 :

Astuce : Souvenez-vous de ce processus en deux étapes lorsque vous essayez de trier la configuration de la musique d'attente et de résoudre les problèmes.

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 :

1. Source de musique configurée sur le nom de domaine (DN)

2. Source de musique configurée sur le périphérique

3. Source de musique sur le profil de périphérique (source de musique d'attente utilisateur uniquement)

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

Note: Pour MoH, CUCM envoie l'adresse de multidiffusion (239.1.1.1, par exemple) comme adresse réseau.

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 :

1. Le flux audio actuel est désactivé.

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

Note: Cela n'affecte pas la signalisation MoH avec CUBE.

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.

Note: Le transcodeur référencé ici est inséré par CUBE (par opposition à CUCM). En ce qui concerne CUCM, le CUBE est la destination, et il n'implique aucun transcodeur dans le chemin du serveur d'attente musicale vers CUBE.

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.

Note: Cette rubrique n'est pas couverte par ce document, car il existe déjà de nombreux bons documents pour des considérations de codec, et il serait superflu de la couvrir ici.

MoH

Note: La plupart des informations décrites dans ce document sont pertinentes jusqu'à présent, que la musique d'attente soit diffusée avec des paquets IP de monodiffusion ou de multidiffusion.

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 :

1. CUBE reçoit les paquets MMoH du serveur de musique d'attente.

2. Il convertit les paquets en paquets IP de monodiffusion.

3. 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 :

Note: CUBE doit exécuter Cisco IOS version 15.2(2)T ou ultérieure afin de prendre en charge la technologie MMoH.

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 :

1. 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).

2. Attribuez un MRGL à la liaison avec le MRG configuré à l'étape 1.

3. Configurez le codec dans les paramètres du service d'application de diffusion vocale en continu IP.

Note: Reportez-vous à la section Musique d'attente de l'article Cisco Unified Communications System 9.0 SRND - Media Resources pour obtenir des instructions détaillées sur la configuration.

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]

Note: Les transcodeurs sont également des MTP.

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

Show voip rtp conn

Show sip calls
Voici un exemple de sortie de la première commande :
R1#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 :

Note: Référez-vous à l'ID de bogue Cisco CSCtx84013 pour plus d'informations.

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.