Voz y Comunicaciones unificadas : Cisco Unified Border Element

MMoH a través de la operación del CUBO, de la configuración, y de la guía del Troubleshooting

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe la operación, la configuración, y la información de Troubleshooting para el Música-en-control del Multicast (MMoH) a través del Cisco Unified Border Element (CUBO).

Aunque el foco de este documento sea Música-en-control del Multicast (moh), una parte sustancial se dedica a describir cómo el moh trabaja en general. Esta información adicional ayuda a la estructura un base-conocimiento para el principiante para reconocer y apreciar mejor los problemas que son específicos a MMoH.

Nota: Mientras que los principios son lo mismo, Cisco unificó el proveedor del Elemento-servicio de la frontera que la edición (CUBE-SP) no cae dentro del ámbito de este documento, ni CUBICA el uso en los entornos que no implican al administrador de las Comunicaciones unificadas de Cisco (CUCM).

Contribuido por Bakthavatsal Muralidharan, ingeniero de Cisco TAC.

Prerrequisitos

Requisitos 

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Antecedente

Nota: A excepción de un par de escenarios que se ilustren para H.323, la señalización del Session Initiation Protocol (SIP) se utiliza en la mayor parte de este documento.

Descripción del moh

Se juega el moh siempre que un llamador sea en espera colocado. el Llamada-control es iniciado por el usuario o por la red cuando se implementa un proceso del servicio suplementario, por ejemplo la llamada adelante o la transferencia. Se refiere el anterior como control, usuario-control, o control usuario-iniciado del usuario. Se refiere este último como control, red-control, o control red-iniciado de la red.

Aquí está un estudio de cómo el moh trabaja con los gatewayes de la multiplexación de división de tiempo (TDM). Esta imagen ilustra los componentes y las conexiones implicados en un escenario del llamada-control:

 

Para poner una llamada en espera, un proceso de dos pasos es necesario. Esta imagen ilustra los dos pasos implicados:

 

Consejo: Recuerde este proceso de dos pasos cuando usted intenta clasificar con la configuración del moh y resolver problemas los problemas.

Fuentes del moh

Refieren al usuario que pone una llamada en espera como el tenedor, y el usuario que es en espera colocado (y oye el moh) se refiere como el holdee. Cada lado decide a ciertos aspectos de la música se juega que.

 

La fuente de la música es determinada por el tenedor. La determinación sigue esta jerarquía:

  1. La fuente de música configurada en el Domain Name (DN)
  2. La fuente de música configurada en el dispositivo
  3. La fuente de música en el perfil del dispositivo (fuente de música del usuario-control solamente)
  4. La fuente de música en el nivel global (parámetro de servicio, o el ejemplo)

Hay dos conjuntos de las fuentes de música, llamados usuario-control y red-control. Siempre que la referencia se haga a la fuente de música, podría significar un usuario-control o la fuente de música del red-control.

Puntos finales del moh

Para los propósitos del moh, el punto final en el lado CUCM es el servidor del moh. Esto es importante entender porque la determinación del codificador-decodificador (basada en la configuración de códec de la inter-región) se basa encendido:

  • La región del servidor del moh
  • La región del trunk/del gateway

El recommedation general es asignar al servidor del moh una región dedicada, de modo que el codificador-decodificador de la inter-región entre esa región y el resto de las regiones sea el g.711 (o el otro codificador-decodificador que usted quiere para fluir hacia fuera para el moh).

De la perspectiva CUCM, los puntos finales implicados en la llamada no son los dos teléfonos, pero bastante:

  • El teléfono del IP registrado a CUCM
  • El gateway/CUBE

Así, CUCM trata el trunk que señala al gateway/CUBE en la pregunta como el punto final, y mira en los recursos asociados a él para determinar cómo rendir la secuencia de la música.

Protocolo VoIP del moh

El moh, por definición, es una conversación del audio unidireccional. Cómo se señala depende del protocolo VoIP usado. Por ejemplo, en el SORBO, esto se transporta vía el atributo de la dirección. En H.323, el CUCM especifica 00000000 como la dirección de red y 0 como el puerto (más tsapIdentifier) del servidor del moh en el mensaje abierto Ack del canal lógico H.245 (OLCAck).

Nota: Para MMoH, CUCM envía a la dirección Multicast (239.1.1.1, por ejemplo) como la dirección de red.

En los flujos de llamada que implican el CUBO, el CUCM no tiene ningún conocimiento sobre el tramo de llamada entre el CUBO y el proveedor de servicio de la telefonía por Internet (ITSP). El CUCM se refiere solamente al tramo de llamada entre el teléfono del IP y el trunk del SORBO (que llevan PARA CUBICAR).

El proceso de la señalización para el moh es similar a la señalización para una nueva conversación, con el alcance reducido. En el SORBO, por ejemplo, la conversación ocurre en el contexto del diálogo que existe ya .[1]

Inhabilite la secuencia de medios

El primer paso en el proceso de dos pasos previamente mencionado es inhabilitar la secuencia de medios.

Esta imagen ilustra cómo la secuencia de medios se inhabilita en el SORBO:

 

¿Las implementaciones del SORBO varían si un o ambo atributos (? ¿a=? ¿y? C=IN?) se utilizan para indicar que la secuencia de medios está inhabilitada.

Esta imagen ilustra cómo la secuencia de medios se inhabilita en H.323:

  

Conecte con el moh

El segundo paso en el proceso de dos pasos previamente mencionado es conectar con el moh. Una vez que se inhabilita la secuencia de audio, CUCM señala la conversación unidireccional del moh que hace el holdee escuchar la fuente del moh.

Como parte de este proceso, CUCM tiene en cuenta las capacidades de los media del holdee y de la lista del grupo de los recursos del medio (MRGL) asociados al trunk antes de que determine los parámetros para fluir. Por consiguiente, la señalización para esto es siempre oferta retrasada (HAGA) [2] (en el SORBO).

El número real de INVITA a las transacciones varía. Por ejemplo, CUCM conecta el holdee con el moh con apenas uno INVITA a la transacción. Alternativamente, INVITE se utiliza para recolectar las capacidades de los media del holdee, y un EO subsiguiente INVITA se utiliza para conectar realmente el holdee con el moh.

Esta imagen ilustra la transacción para el SORBO:

Esta imagen ilustra la transacción para H.323:

Esta imagen ilustra la secuencia del mensaje de señalización en un entorno que intertrabaja (cuando un lado de CUBO es el SORBO y el otro lado H.323, por ejemplo):

 

Cuando utilizan a los recursos del medio en una llamada

Blindaje de los recursos del medio (MediaTermination punta ()/transcoders MTP) el tramo de llamada del proveedor de servicio las Cubo-a-TIC (ITSP) en general. Cuando utilizan a los recursos del medio en una llamada a través del CUBO, la señalización para el moh implica sobre todo los mensajes del protocolo skinny client control (SCCP) entre CUCM y los recursos del medio. Note que es los recursos del medio que se ponen en el control, no el trunk del CUBO. Después de que el MTP/Transcoder se señale para escuchar el moh (SORBO asumido), CUCM envía un mensaje de actualización del SORBO PARA CUBICAR. Esto pone al día el parámetro de bifurcación, que identifica la nueva transacción (la conversación MOH).

Reanude la llamada

El proceso del curriculum vitae es similar al proceso del control, salvo que se invierte la orden:

  1. Se inhabilita la secuencia de audio actual.
  2. Otros re-INVITAN se envían para volver a conectar el holdee al teléfono que puso la llamada en espera. 

Atributo SDP

Los X-Cisco-media: el atributo del umoh en el protocolo session description (SDP) fue introducido para simplificar el moh que señalaba sobre los links troncales del Inter-cluster (ICT) [3]. Con el interoperation entre los puntos finales que utilizan diversos protocolos, CUCM realiza a menudo la señalización torpe e intermedia que es NON-intuitiva. Para evitar la conjetura, y hacer la señalización contexto-explícita, se utiliza un atributo propietario SDP, los X-Cisco-media Nombrados.

Con las versiones 8.5 CUCM y posterior, el moh se puede [4] señalar con este conjunto del atributo a la música del unicast en el control (UMoH) o a MMoH, que quitan la confianza en un valor de puerto falso para indicar un escenario del moh al sostener-partido.

Nota: Esto no afecta al moh que señala con el CUBO.

Moh en el CUBO

Con el CUBO, el proceso básico sigue siendo lo mismo; sin embargo, es importante considerar que [5] el CUBO no transcodifica el moh hasta la versión 15.3T del � del Cisco IOS. Esto significa que usted debe tener cuidado con los factores que influencian la selección de códec en la pierna del CUCM-a-CUBO de modo que un transcoder no sea necesario.

Nota: El transcoder referido aquí es insertado por el CUBO (en comparación con CUCM). Por lo que CUCM, el CUBO es el destino, y no implica ningún transcoder en la trayectoria del Servidor-a-CUBO MOH.

Consideraciones del codificador-decodificador

Varios factores afectan generalmente al codificador-decodificador usado en la pierna del CUCM-a-CUBO, pero estas consideraciones solicitan el moh:

  • El moh no puede ser transcodificado. [5]
  • Sonidos del moh buenos solamente con G.711.

Nota: Este tema está fuera del ámbito de este documento porque muchos buenos documentos existen ya en las consideraciones del codificador-decodificador, y sería redundante cubrirlo aquí.

MMoH

Nota: La mayor parte de la información descrita en este documento hasta el momento es relevante si el moh está fluido con el unicast o los paquetes del IP de multidifusión.

MMoH conserva los recursos del sistema y el ancho de banda. El Multicast permite que los usuarios múltiples utilicen la misma secuencia de la fuente de audio para proporcionar la música en espera. MMoH es deseable en cualquier red corporativa donde están importantes los ahorros del ancho de banda.

Aquí están algunas preocupaciones y problemas cuando el CUBO pasa MMoH sobre Internet al ITSP:

  • Alcance del tráfico Multicast - Cisco utiliza el rango 239.0.0.0 a 239.255.255.255 para la música del Multicast. Este rango se conoce como administrativo direccionamientos del scoped. Este bloque se considera soldado, así que significa que es utilizado por las redes para empresas, y debe nunca ser remitido fuera de la empresa. Los routeres delimitador se configuran generalmente por consiguiente.
  • Multicast sobre el VPN - Por abandono, la seguridad IP no soporta MMoH.

Éste es cómo el CUBO soporta MMoH:

  1. El CUBO recibe los paquetes de MMoH del servidor del moh.
  2. Convierte los paquetes en los paquetes IP del unicast.
  3. CUBO adelante los paquetes al ITSP.

Manipulación del atributo de la dirección del SORBO

Según lo descrito en el RFC 3264:

“Si una descripción de sesión contiene una secuencia de medios del Multicast como la cual se enumere reciben (envíe) solamente, significa que los participantes, incluyendo el contratista y el answerer, pueden recibir solamente (enviar) en esa secuencia. Esto diferencia de la opinión del unicast, donde la direccionalidad refiere al flujo de media entre el contratista y el answerer. Más allá de esa clarificación, la semántica de una secuencia de multidifusión ofrecida está exactamente según lo descrito en el RFC 2327 el [1]"

Por consiguiente, cuando CUCM envía una re-INVITACIÓN con un Multicast IP Address, fija el atributo de la dirección a recvonly; sin embargo, puesto que el CUBO convierte los paquetes de multidifusión en los paquetes de unidifusión, debe fijar el atributo de la dirección a sendonly en la pierna con el ITSP.

Esta imagen ilustra la lógica:

  

Manipulación del direccionamiento

En el DO[6] re-INVITE enviado para conectar al llamador ITSP con la fuente del moh, CUBO envía su propia dirección IP en el campo del SORBO SDP C=IN. Esto es una dirección de Unicast.

Esta imagen proporciona la visión de extremo a extremo:

 

Nota: El CUBO debe funcionar con la versión deL Cisco IOS para soportar 15.2(2)T o más adelante MMoH. 

Secuencia de un Flash

Con los gatewayes TDM, los ahorros adicionales del ancho de banda WAN son observados fluyendo la derecha de la música del Multicast del gateway. Así, si el servidor del moh está en las jefaturas, y el gateway está en una sucursal remota a través de una conexión WAN, el tráfico Multicast que lleva el moh no tiene que atravesar WAN (de las jefaturas a la bifurcación) y utilizar el ancho de banda WAN valioso.

El CUBO es un dispositivo del lado troncal que no es capaz de fluir MMoH que sea originado del flash local o vía cualquier interfaz analogica TDM. Es todavía posible realizar el ancho de banda WAN. Esto se logra con el uso de otro router activado mediante la voz en la sucursal remota como la fuente de la secuencia de MMoH. Este router fluye MMoH del flash. El CUBO se puede entonces señalar para recibir esos paquetes, convertirlos, y pasarlos encendido como paquetes de unidifusión.

Secuencia de una transmisión en directo

Para fluir de una transmisión en directo, otro router debe ser configurado porque el CUBO no es un dispositivo del lado de la línea, como se debate en la sección anterior.

Configuración MMoH

Esta sección describe cómo configurar MMoH en el Switches del CUBO, CUCM, y L3-capable.


Configuración MMoH en el CUBO

Utilice estos comandos para configurar MMoH en el CUBO:

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

Configure MMoH en CUCM

Siga los siguientes pasos para configurar MMoH en CUCM:

  1. Habilite la capacidad de multidifusión en la fuente del moh, el servidor del moh, y el grupo de los recursos del medio (MRG).
  2. Asigne un MRGL al trunk con el MRG configurado en el paso 1.
  3. Configure el codificador-decodificador en los parámetros del servicio de aplicación IP Voz-que fluyen.

Nota: Refiera a la música en la sección del control del Cisco Unified Communications System 9.0 SRND - artículo de los recursos del medio para los pasos de la configuración detallada.

Configure MMoH en el Switches L3-Capable

Utilice estos comandos para configurar MMoH en el Switches L3-capable:

ip routing
ip multicast-routing

Cuando el MTP se utiliza en una llamada

Los MTP no soportan la música del Multicast. El holdee recibe solamente dead-air.[7]

Nota: El transcoders es MTP también.

Consideraciones de rendimiento

Todos los paquetes MMOH son proceso conmutado en el Cisco IOS. Ésta es muy bien para pequeñas implementaciones, pero tiene un impacto significativo en el funcionamiento del CUBO para las instalaciones grandes.

Restricciones

Aquí está una lista de restricciones con el uso de MMoH:

  • El CUBO debe estar en la versión deL Cisco IOS 15.2(2)T o más adelante.
  • MMoH no se soporta en AS54xx.
  • MMoH no se soporta en el ISR-G1s (28xx, las 38xx Series)
  • Sea consciente del codecs se soporta que.

Troubleshooting

Utilice esta sección para resolver problemas MMoH. 

comandos show y debug

Aquí está una lista de comandos show and debug, y sus significados:

  • Muestre la música del CCM-administrador - Las ayudas confirman que el CUBO sabe dónde estar atentos los paquetes de la música del Multicast, y también si los recibe.
    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 
  • Muestre a los miembros del igmp del IP - Utilizado para marcar si el CUBO se unió a con éxito al grupo de multidifusión cuando estaba señalado para escuchar la música del Multicast.

  • Estos tres comandos se utilizan para marcar el codificador-decodificador, la dirección IP, y los números del puerto negociados de los puntos finales:
    Show call active voice compact
    Show voip rtp conn
    Show sip calls
    Aquí está una salida de ejemplo del primer comando:
    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
  • Muestre a problema del escrito de la voz activa de la llamada este comando cuando la llamada es en espera para marcar si las cuentas del rx/tx incrementan.
    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
  • Muestre la clase “dispositivo MOH de la interrogación perforación de Cisco” - utilizan a este comando CLI CUCM para marcar rápidamente si afectan un aparato los recursos MOH, y qué clase (unicast o Multicast). Este comando no es muy útil cuando usted tiene ninguno-control de las varias llamadas, como el cambio de las cuentas dinámicamente cuando las llamadas son en espera puesto y reanudado.
    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
  • Música-en-control del CCM-administrador del debug - Se utiliza este comando para localizar cómo los tramos de llamada se cambian (cuando usted inhabilita el audio actual y conecta el moh, por ejemplo), así como verificarlo si el CUBO se une a al grupo del Internet Group Management Protocol (IGMP) según lo dado instrucciones por CUCM.
  • Paquete del IP del debug - Este comando se utiliza como alternativa a Wireshark para los controles. Sin embargo, este comando puede abrumar rápidamente el CPU. Utilícelo solamente cuando absolutamente es necesario; apague el registro de la consola, y no lo ejecute para más que un segundo.

Escenario 1

Síntoma - Una llamada del Public Switched Telephone Network (PSTN) establece muy bien con el audio de dos vías. Sin embargo, cuando el teléfono del IP coloca al llamador PSTN en espera y después reanuda la llamada, el audio unidireccional resulta: el teléfono del IP oye el audio del PSTN, pero el usuario PSTN no puede oír el teléfono del IP.

Primero, aseegurese que requiera el SDP que el intercambio inactivo para el cambio de los media de la Mediados de-llamada no se inhabilita en el trunk del SORBO en question[5]. El es qué permite a CUCM para enviar una re-INVITACIÓN con a=inactive en el SDP, para romper el trayecto de medios que existe.

Cuando la llamada es en espera puesto, CUCM no envía una re-INVITACIÓN con un SDP inactivo para romper el trayecto de medios si Send enviar-recibe el SDP en la mediados de-llamada INVITA a la casilla de verificación se habilita para el SORBO trunk[8]. Esa configuración se marca solamente para saber si hay dispositivos que no puedan proporcionar una oferta completa (del enviar-recv) después de que el modo de los media se fije a inactivo.

Aquí están las imágenes que ilustran las casillas de verificación disponibles:

Nota: Refiera al Id. de bug Cisco CSCtx84013 para la información adicional.

Escenario 2

Síntoma - Hay solamente un tono cuando los llamadores son en espera colocado en vez de MMoH.

Generalmente, esto sugiere que CUCM no afectara un aparato MMoH.

  • ¿Utilice la clase de la interrogación perforación de la demostración? ¿Dispositivo MOH de Cisco? Comando CLI CUCM para verificar si la cuenta de MOHOutOfResources incrementa.
  • Asegúrese de que el Multicast esté habilitado en la fuente, el servidor, y el grupo de MMoH.

Escenario 3

Síntoma - Solamente se oye la interrupción en la comunicación cuando un llamador es en espera colocado.

Asegúrese de lo siguiente:  

  • El ruteo multicast se habilita en el CUBO y el otro Routers en el trayecto de audio.
  • El Routing IP y el ruteo multicast se habilitan en el Switches L3 en el trayecto de audio.
  • La TTL (conteo saltos) se configura en el servidor del moh en CUCM, y es bastante grande cubrir los saltos.
  • Si se requiere un transcoder, se afecta un aparato con éxito.
  • La lista de codecs configurada en la aplicación de flujo continuo de la Voz IP soporta el codificador-decodificador usado para el moh.

Situación 4

Síntoma - Una llamada falla en flujo-alrededor del modo para el control y el curriculum vitae de la llamada.

Para soportar flujo-alrededor de, usted debe enviar una re-INVITACIÓN o una actualización del IPIPGW; sin embargo, esto no se soporta actualmente. Por lo tanto, flujo-alrededor con de las llamadas DO-EO no se soporta. Si hay tal requisito del flujo de llamada del márketing, una consideración para el soporte será hecha. El bug Cisco, SORBO SS DO-EO del SORBO: La llamada falla en el flujo alrededor del modo para el control de la llamada y el curriculum vitae, se marca como mejora para la consideración en el futuro.

Información Relacionada



¿[1] esto puede estar confuso cómo puede usted tener una diversa conversación dentro de un diálogo? Bien, en el SORBO, el diálogo refiere a la etiqueta del <To 3-tupe, de la etiqueta, y Call-ID>. Este 3-tupe sigue siendo lo mismo durante la fase del control.

[2] HAGA - Oferta retrasada.

[3] tronco entre clústerss

[4] a partir de CUCM 8.5.

[5] la transcodificación trabaja para MMoH en las versiones deL Cisco IOS 15.3T y posterior. 

[6] HACEN - Oferta retrasada

El administrador de las Comunicaciones unificadas [7] Cisco ofrece y mantiene la guía, versión 8.6(1)

[8] éstas son configuraciones en el perfil del SORBO usado para configurar el trunk del SORBO.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 116392