Voix et communications unifiées : Logiciel Cisco Unified Border Element

MMoH par l'exécution de CUBE, configuration, et dépannent le guide

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit l'exécution, la configuration, et l'information de dépannage pour la musique d'attente de Multidiffusion (MMoH) par le Logiciel Cisco Unified Border Element (CUBE).

Bien que le centre de ce document soit multidiffusé la musique d'attente (MoH), une partie notable est consacrée à décrire comment le MoH fonctionne en général. Ces informations complémentaires aident la construction une base-connaissance pour le débutant afin de mieux identifier et apprécier les questions qui sont spécifiques à MMoH.

Remarque: Tandis que les principes sont mêmes, l'édition de fournisseur d'Élément-services de cadre de Cisco Unified (CUBE-SP) ne tombe pas à portée de ce document, ni CUBE l'utilisation dans les environnements qui n'impliquent pas Cisco Unified Communications Manager (CUCM).

Contribué par Bakthavatsal Muralidharan, ingénieur TAC Cisco.

Conditions préalables

Conditions requises 

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Fond

Remarque: Excepté quelques scénarios qui sont illustrés pour H.323, la signalisation de Protocole SIP (Session Initiation Protocol) est utilisée dans toute la majeure partie de ce document.

Aperçu MoH

Le MoH est lu toutes les fois qu'un appelant est en attente placé. L'appel en attente est initié par l'utilisateur ou par le réseau quand un processus supplémentaire de service est mis en application, comme l'appel en avant ou le transfert. L'ancien est mentionné comme attente, utilisateur-attente, ou attente utilisateur-initiée d'utilisateur. Ce dernier est mentionné comme attente, réseau-attente, ou attente réseau-initiée de réseau.

Voici un examen de la façon dont le MoH fonctionne avec des passerelles du multiplexage temporel (TDM). Cette image illustre les composants et les connexions impliqués dans un scénario d'appel en attente :

 

Afin de placer un appel en attente, un processus en deux étapes est nécessaire. Cette image illustre les deux étapes impliquées :

 

Conseil : Souvenez-vous ce processus en deux étapes quand vous tentez de trier par la configuration MoH et de dépanner des questions.

Sources MoH

L'utilisateur qui place un appel en attente désigné sous le nom du titulaire, et de l'utilisateur qui est en attente placé (et entend le MoH) désigné sous le nom du holdee. Chaque côté décide certains aspects de la musique qui est lue.

 

La source de musique est déterminée par le titulaire. La détermination suit cette hiérarchie :

  1. La source de musique configurée sur le nom de domaine (DN)
  2. La source de musique configurée sur le périphérique
  3. La source de musique sur le profil de périphérique (source de musique d'utilisateur-attente seulement)
  4. La source de musique au niveau global (paramètre de service, ou à l'exemple)

Il y a deux ensembles de sources de musique, appelés utilisateur-attente et la réseau-attente. Toutes les fois que la référence est faite à la source de musique, elle pourrait signifier une utilisateur-attente ou la source de musique de réseau-attente.

Points finaux MoH

Pour le MoH, le point final du côté CUCM est le serveur MoH. Il est important comprendre ce parce que la détermination de codecs (basée sur la configuration de codecs d'inter-région) est basée en fonction :

  • La région de serveur MoH
  • La région de joncteur réseau/passerelle

Le recommedation général est d'assigner au serveur MoH une région dédiée, de sorte que le codec d'inter-région entre cette région et toutes autres régions soit le G.711 (ou tout autre codec que vous voulez pour couler pour le MoH).

Du point de vue CUCM, les points finaux impliqués dans l'appel ne sont pas les deux téléphones, mais plutôt :

  • Le téléphone IP enregistré à CUCM
  • Le gateway/CUBE

Ainsi, CUCM traite le joncteur réseau qui indique le gateway/CUBE en question comme point final, et des aspects dans les ressources associées avec lui afin de déterminer comment rendre le flot de musique.

MoH VoIP Protocol

Le MoH, par définition, est une conversation sonore à sens unique. Comment on le signale dépend du protocole VoIP utilisé. Par exemple, sur le SIP, ceci est transporté par l'intermédiaire de l'attribut de direction. Sur H.323, le CUCM spécifie 00000000 comme adresse réseau et 0 comme port (tsapIdentifier) du serveur MoH dans le H.245 ouvrent le message du canal logique ACK (OLCAck).

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

Dans les écoulements d'appel qui impliquent le CUBE, le CUCM n'a aucune connaissance au sujet du l'appel-tronçon entre le CUBE et le fournisseur de service téléphonique Internet (ITSP). Le CUCM est seulement concerné par l'appel-tronçon entre le téléphone IP et le joncteur réseau de SIP (menant POUR CUBER).

Le processus de la signalisation pour le MoH est semblable à la signalisation pour une nouvelle conversation, avec la portée réduite. Dans le SIP, par exemple, la conversation a lieu dans le contexte du dialogue qui existe déjà .[1]

Désactivez le flux multimédia

La première étape dans le processus en deux étapes précédemment mentionné est de désactiver le flux multimédia.

Cette image illustre comment le flux multimédia est désactivé dans le SIP :

 

Les réalisations de SIP varient si 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 illustre comment le flux multimédia est désactivé dans H.323 :

  

Connectez au MoH

La deuxième étape dans le processus en deux étapes précédemment mentionné est de se connecter au MoH. Une fois que le flux audio est désactivé, CUCM signale la conversation à sens unique MoH qui fait écouter le holdee la source MoH.

En tant qu'élément de ce processus, CUCM prend en considération les capacités de medias du holdee et de la liste de groupe de ressources de medias (MRGL) associés avec le joncteur réseau avant qu'il détermine les paramètres pour couler. En conséquence, la signalisation pour ceci est toujours l'offre retardée (FAITES) [2] (dans le SIP).

Le nombre réel de INVITENT des transactions varient. Par exemple, CUCM connecte le holdee au MoH juste à un INVITE la transaction. Alternativement, INVITEZ est utilisé afin de recueillir les capacités de medias du holdee, et un ordre technique ultérieur INVITENT est utilisé afin de connecter réellement le holdee au MoH.

Cette image illustre la transaction pour le SIP :

Cette image illustre la transaction pour H.323 :

Cette image illustre l'ordre de message de signalisation dans un environnement d'interworking (quand un côté de CUBE est SIP et l'autre côté H.323, par exemple) :

 

Quand des ressources en medias sont utilisées dans un appel

Bouclier de ressources en medias (point de MediaTermination (MTP)/transcodeurs) l'appel-tronçon du fournisseur de services de Cube-à-service informatique (ITSP) pour la plupart. Quand une ressource en medias est utilisée dans un appel par le CUBE, la signalisation pour le MoH implique en grande partie des messages de Skinny Client Control Protocol (SCCP) entre CUCM et la ressource en medias. Notez que c'est la ressource en medias qui est mise sur l'attente, pas le joncteur réseau de CUBE. Après que le MTP/Transcoder soit signalé pour écouter MoH (SIP arrogant), CUCM envoie un message de MISE À JOUR de SIP POUR CUBER. Ceci met à jour le paramètre de branchement, qui identifie la nouvelle transaction (la conversation MOH).

Reprenez l'appel

Le procédé de reprise est semblable au procédé d'attente, sauf que la commande est renversée :

  1. Le flux audio en cours est désactivé.
  2. Des autres re-INVITENT sont envoyés afin de rebrancher le holdee au téléphone qui a placé l'appel en attente. 

Attribut SDP

Les X-Cisco-medias : l'attribut d'umoh dans la Session Description Protocol (SDP) a été introduit afin de simplifier le MoH signalant au-dessus des joncteurs réseau d'Inter-batterie (ICTs) [3]. Avec l'interopérabilité entre les points finaux qui utilisent différents protocoles, CUCM exécute souvent la signalisation maladroite et intermédiaire qui est non-intuitive. Afin d'éviter la simplicité, et rendre la signalisation contexte-explicite, un attribut de propriété industrielle SDP, des X-Cisco-medias Désignés, est utilisé.

Avec des versions 8.5 et ultérieures CUCM, le MoH peut [4] être signalé avec cet attribut réglé à la musique d'attente d'Unicast (UMoH) ou au MMoH, qui enlèvent la confiance dans une fausse valeur de port pour indiquer un scénario MoH au tenir-interlocuteur.

Remarque: Ceci n'affecte pas la signalisation MoH avec le CUBE.

MoH sur le CUBE

Avec le CUBE, l'opération de base demeure la même ; cependant, il est important de considérer que le CUBE [5] ne transcode pas le MoH jusqu'à la version 15.3T de Ý de Cisco IOS. Ceci signifie que vous devez faire attention avec les facteurs qui influencent la sélection de codecs dans le tronçon de CUCM-à-CUBE de sorte qu'un transcodeur ne soit pas nécessaire.

Remarque: Le transcodeur référencé ici est inséré par le CUBE (par opposition à CUCM). En ce qui concerne CUCM, le CUBE est la destination, et il n'implique aucun transcodeur dans le chemin de Serveur-à-CUBE MOH.

Considérations de codecs

Généralement plusieurs facteurs affectent les codecs utilisés dans le tronçon de CUCM-à-CUBE, mais ces considérations s'appliquent pour le MoH :

  • Le MoH ne peut pas être transcodé. [5]
  • Le MoH retentit bon seulement avec G.711.

Remarque: Ce thème est hors de portée de ce document parce que beaucoup de bons documents existent déjà sur des considérations de codecs, et il serait redondant de le couvrir ici.

MMoH

Remarque: La majeure partie des informations décrites dans ce document est jusqu'ici appropriée si le MoH soit coulé avec des paquets d'unicast ou de multicast IP.

MMoH économise des ressources système et la bande passante. La Multidiffusion permet à des plusieurs utilisateurs pour employer le même flot de source audio afin de fournir la musique d'attente. MMoH est desirable dans n'importe quel réseau d'entreprise où le gain de bande passante est important.

Voici quelques soucis et questions quand le CUBE passe MMoH au-dessus de l'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 en tant qu'adresses administrativement scoped. Ce bloc est considéré privé, ainsi il signifie qu'il est utilisé par des réseaux d'entreprise, et devrait ne jamais être expédié en dehors de l'entreprise. Les Routeurs de borne sont habituellement configurés en conséquence.
  • Multidiffusion au-dessus de VPN - Par défaut, la sécurité IP ne prend en charge pas MMoH.

C'est comment le CUBE prend en charge MMoH :

  1. Le CUBE reçoit les paquets de MMoH du serveur MoH.
  2. Il convertit les paquets en paquets IP d'unicast.
  3. CUBE en avant les paquets à ITSP.

Manipulation d'attribut de direction de SIP

Comme décrit dans RFC 3264 :

« Si une description de session contient un flux multimédia de Multidiffusion qui est répertorié comme reçoivent (envoyez) seulement, il signifie que les participants, y compris le soumissionnaire et l'answerer, peuvent seulement recevoir (envoyer) sur ce flot. Ceci diffère de la vue d'unicast, où la directionnalité se rapporte à l'écoulement des medias entre le soumissionnaire et l'answerer. Au delà de cette clarification, la sémantique d'un flot offert de Multidiffusion sont exactement comme décrit dans RFC 2327 [1]"

En conséquence, quand CUCM envoie une re-INVITATION avec une adresse IP de Multidiffusion, il place l'attribut de direction à recvonly ; cependant, puisque le CUBE convertit les paquets de multidiffusion en paquets monodiffusions, il doit placer l'attribut de direction à sendonly sur le tronçon avec ITSP.

Cette image illustre la logique :

  

Manipulation d'adresse

Dans le DO[6] re-INVITEZ envoyé afin de connecter l'appelant ITSP à la source MoH, CUBE envoie sa propre adresse IP dans le domaine du SIP SDP C=IN. C'est une adresse de monodiffusion.

Cette image fournit la vue de bout en bout :

 

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

Flot d'un éclair

Avec des passerelles TDM, le gain de bande passante BLÊME supplémentaire est réalisé en coulant le juste de musique de Multidiffusion de la passerelle. Ainsi, si le serveur MoH est aux sièges sociaux, et la passerelle est à une filiale distante à travers une connexion WAN, le trafic de multidiffusion qui porte le MoH ne doit pas traverser le WAN (des sièges sociaux au branchement) et utiliser l'importante bande passante BLÊME.

Le CUBE est un périphérique de joncteur réseau-side qui n'est pas capable de couler MMoH qui est originaire de l'éclair local ou par l'intermédiaire de n'importe quelle interface analogique TDM. Il est encore possible de réaliser la bande passante BLÊME. Ceci est accompli avec l'utilisation d'un autre routeur activé par la voix à la filiale distante comme source du flot de MMoH. Ce routeur coule MMoH de l'éclair. Le CUBE peut alors être signalé afin de recevoir ces paquets, les convertir, et les passer en fonction comme paquets monodiffusions.

Flot d'un flux en direct

Afin de couler d'un flux en direct, un autre routeur doit être configuré parce que le CUBE n'est pas un périphérique de ligne-side, comme évoqué dans la section précédente.

Configurez MMoH

Cette section décrit comment configurer MMoH sur des Commutateurs de CUBE, CUCM, et L3-capable.


Configurez MMoH sur le CUBE

Employez ces commandes afin de configurer MMoH sur le CUBE :

ccm-manager music-on-hold
ip multicast-routing

Configurez MMoH sur CUCM

Suivez ces étapes afin de configurer MMoH sur CUCM :

  1. Activez la capacité multicast sur la source MoH, le serveur MoH, et le groupe de ressources de medias (MRG).
  2. Assignez un MRGL au joncteur réseau avec le MRG configuré dans l'étape 1.
  3. Configurez les codecs dans des paramètres de service Voix-coulants d'application IP.

Remarque: Référez-vous à la section de musique d'attente du Système de communications unifiées Cisco 9.0 SRND - article de ressources en medias pour des étapes de configuration détaillée.

Configurez MMoH sur des Commutateurs L3-Capable

Employez ces commandes afin de configurer MMoH sur des Commutateurs L3-capable :

ip routing
ip multicast-routing

Quand MTP est utilisé dans un appel

MTPs ne prennent en charge pas la musique de Multidiffusion. Le holdee reçoit seulement dead-air.[7]

Remarque: Les transcodeurs sont MTPs également.

Considérations de représentation

Tous les paquets MMOH sont commutés par processus dans le Cisco IOS. C'est bien pour de petits déploiements, mais a un impact important sur la représentation du CUBE pour de grandes installations.

Restrictions

Voici une liste de restrictions avec l'utilisation de MMoH :

  • Le CUBE doit être à la version 15.2(2)T ou ultérieures de Cisco IOS.
  • MMoH n'est pas pris en charge sur AS54xx.
  • MMoH n'est pas pris en charge sur ISR-G1s (28xx, la gamme 38xx)
  • Rendez-vous compte des codecs qui sont pris en charge.

Dépannez

Employez cette section afin de dépanner MMoH. 

Commandes d'exposition et de debug

Voici une liste de commandes d'exposition et de débogage, et leurs significations :

  • Musique de show ccm-manager - Les aides confirment que le CUBE sait où écouter des paquets de musique de Multidiffusion, et aussi si elle 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 
  • Membres d'igmp de show ip - Utilisé afin de vérifier si le CUBE joignait avec succès le groupe de multidiffusion une fois signalé pour écouter la musique de Multidiffusion.

  • Ces trois commandes sont utilisées afin de vérifier les codecs, l'adresse IP, et les numéros de port négociés des points finaux :
    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
  • Brève question de show call active voice cette commande quand l'appel est en attente afin de vérifier si les comptes rx/tx incrémentent.
    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
  • Affichez la classe « périphérique de requête perforation de Cisco MOH » - cette commande CUCM CLI est utilisée afin de vérifier rapidement si une ressource MoH est allouée, et quelle sorte (unicast ou Multidiffusion). Cette commande n'est pas très utile quand vous avez la plusieurs NO--attente d'appels, comme modification de comptes dynamiquement quand les appels sont en attente mis 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
  • Musique d'attente de debug ccm-manager - Cette commande est utilisée afin de tracer comment les appel-tronçons sont changés (quand vous désactivez l'audio en cours et connectez le MoH, par exemple), aussi bien que vérifier si le CUBE joint le groupe de Protocole IGMP (Internet Group Management Protocol) comme instruit par CUCM.
  • Debug ip packet - Cette commande est utilisée comme alternative à Wireshark pour des contrôles. Cependant, cette commande peut rapidement accabler la CPU. Utilisez-le seulement si absolument nécessaire ; arrêtez la journalisation console, et ne l'exécutez pas pour plus qu'une seconde.

Scénario 1

Symptôme - Un appel du réseau téléphonique public commuté (PSTN) établit bien avec l'audio bi-directionnel. Cependant, quand le téléphone IP place l'appelant PSTN en attente et puis reprend l'appel, résultats sonores à sens unique : le téléphone IP entend l'audio du PSTN, mais l'utilisateur PSTN ne peut pas entendre le téléphone IP.

D'abord, assurez-vous qu'exigez le SDP l'échange qu'inactif pour la modification de medias de Mid-appel n'est pas désactivé sur le joncteur réseau de SIP dans question[5]. C'est ce qui permet à CUCM d'envoyer une re-INVITATION avec a=inactive dans le SDP, afin de casser le chemin de medias qui existe.

Quand l'appel est en attente mis, CUCM n'envoie pas une re-INVITATION avec un SDP inactif afin de casser le chemin de medias si l'émission-réception SDP d'envoi dans le mid-appel INVITENT la case est activée pour le SIP trunk[8]. Cette configuration est examinée seulement pour assurer les périphériques qui ne peuvent pas fournir une pleine (envoyez-recv) offre après que le mode de medias soit placé à inactif.

Voici les images qui illustrent les cases disponibles :

Remarque: Référez-vous à l'ID de bogue Cisco CSCtx84013 pour information les informations complémentaires.

Scénario 2

Symptôme - Il y a seulement une tonalité quand les appelants sont en attente placé au lieu de MMoH.

Généralement, ceci suggère que CUCM n'ait pas alloué MMoH.

  • Utilisez la classe de requête perforation d'exposition ? Périphérique de Cisco MOH ? Commande CUCM CLI afin de vérifier si le compte de MOHOutOfResources incrémente.
  • Assurez-vous que la Multidiffusion est activée sur la source, le serveur, et le groupe de MMoH.

Scénario 3

Symptôme - Seulement du mort-air est entendu quand un appelant est en attente placé.

Vérifiez les points suivants :  

  • Le multicast-routing est activé sur le CUBE et d'autres Routeurs dans le chemin audio.
  • Le Routage IP et le multicast-routing sont activés sur les Commutateurs L3 dans le chemin audio.
  • TTL (compte de saut) est configurée sur le serveur MoH sur CUCM, et est assez grande pour couvrir les sauts.
  • Si un transcodeur est exigé, il est alloué avec succès.
  • La liste de codecs configurés sur les applications de diffusion de Voix IP prend en charge les codecs utilisés pour le MoH.

Scénario 4

Symptôme - Un appel échoue dans écoulement-autour du mode pour l'appel en attente et la reprise.

Afin de prendre en charge écoulement-autour de, vous devez envoyer une re-INVITATION ou une mise à jour d'IPIPGW ; cependant, ceci n'est pas actuellement pris en charge. Par conséquent, écoulement-autour avec de DO-EO des appels n'est pas pris en charge. S'il y a une telle condition requise d'appel-écoulement du marketing, une considération pour le support sera faite. La bogue Cisco, SIP solides solubles DO-EO de SIP : L'appel échoue dans l'écoulement autour du mode pour l'appel en attente et la reprise, est marquée comme amélioration pour la considération à l'avenir.

Informations connexes



[1] ceci peut être embrouillant comment pouvez vous avoir une conversation différente dans un dialogue ? Bien, dans le SIP, le dialogue se rapporte à la balise du <To 3-tupe, de la balise, et le Call-ID>. Ce 3-tupe reste le même pendant la phase d'attente.

[2] FONT - Offre retardée.

joncteur réseau d'Inter-batterie [3]

[4] à partir de CUCM 8.5.

Le transcodage [5] fonctionne pour MMoH dans des versions 15.3T et ultérieures de Cisco IOS. 

[6] FONT - Offre retardée

Caractéristiques [7] Cisco Unified Communications Manager et guide de services, version 8.6(1)

[8] ceux-ci sont des configurations sur le profil de SIP utilisé afin de configurer le joncteur réseau de SIP.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116392