Guía de Funcionamiento, Configuración y Troubleshooting de MMoH a través de CUBE
Contenido
Introducción
Este documento describe la operación, la configuración y la información de resolución de problemas para la música en espera multidifusión (MoH) a través de Cisco Unified Border Element (CUBE).
Aunque el foco de este documento es Multicast Music-on-Hold (MoH), una parte sustancial se dedica a describir cómo funciona MoH en general. Esta información adicional ayuda a construir una base de conocimiento para el principiante con el fin de reconocer y apreciar mejor los problemas que son específicos de MMoH.
Prerequisites
Requirements
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.
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.
Background
Descripción general de MoH
Se reproduce MoH siempre que se pone en espera a la persona que llama. La retención de llamada la inicia el usuario o la red cuando se implementa un proceso de servicio complementario, como el reenvío o la transferencia de llamada. El primero se denomina retención iniciada por el usuario, retención de usuario o retención de usuario. Esto último se denomina como retención iniciada por red, retención de red o retención de red.
A continuación se muestra una revisión de cómo funciona MoH con las gateways de multiplexación por división de tiempo (TDM). Esta imagen ilustra los componentes y conexiones involucrados en un escenario de llamada en espera:
Para poner una llamada en espera, se necesita un proceso de dos pasos. Esta imagen ilustra los dos pasos involucrados:
Fuentes de MoH
El usuario que pone una llamada en espera se denomina titular, y el usuario que se pone en espera (y escucha MoH) se denomina titular. Cada lado decide ciertos aspectos de la música que se toca.
El origen de la música lo determina el titular. La determinación sigue a esta jerarquía:
- El origen de música configurado en el nombre de dominio (DN)
- El origen de música configurado en el dispositivo
- El origen de la música en el perfil del dispositivo (sólo fuente de música en espera de usuario)
- El origen de música a nivel global (parámetro de servicio o ejemplo)
Hay dos conjuntos de orígenes de música, denominados user-hold y network-hold. Siempre que se hace referencia al origen de música, puede significar un origen de música en espera de usuario o de espera de red.
Terminales MoH
Para fines de MoH, el terminal del lado de CUCM es el servidor MoH. Esto es importante para comprender porque la determinación del códec (basada en la configuración del códec interregional) se basa en:
- La región del servidor MoH
- La región del tronco/gateway
La recomendación general es asignar al servidor MoH una región dedicada, de modo que el códec interregional entre esa región y todas las demás regiones sea g.711 (u otro códec que desee transmitir para MoH).
Desde la perspectiva de CUCM, los terminales que intervienen en la llamada no son los dos teléfonos, sino más bien:
- El teléfono IP registrado en CUCM
- El gateway/CUBE
Por lo tanto, CUCM trata el tronco que apunta al gateway/CUBE en cuestión como el punto final, y examina los recursos asociados con él para determinar cómo representar el flujo de música.
Protocolo VoIP MoH
MoH, por definición, es una conversación de audio unidireccional. La señalización depende del protocolo VoIP utilizado. Por ejemplo, en SIP, esto se transmite a través del atributo direction. En H.323, CUCM especifica 0000000 como dirección de red y 0 como puerto (tsapIdentifier) del servidor MoH en el mensaje H.245 Open Logical Channel Ack (OLCAck).
En los flujos de llamadas que implican CUBE, CUCM no tiene conocimiento sobre el tramo de llamada entre CUBE y el proveedor de servicios de telefonía por Internet (ITSP). CUCM solo se ocupa del tramo de llamada entre el teléfono IP y el troncal SIP (que conduce a CUBE).
El proceso de señalización para MoH es similar a la señalización para una nueva conversación, con un alcance reducido. En SIP, por ejemplo, la conversación tiene lugar en el contexto del diálogo que ya existe .[1]
Desactivar el flujo de medios
El primer paso en el proceso de dos pasos mencionado anteriormente es inhabilitar la secuencia de medios.
Esta imagen ilustra cómo se inhabilita el flujo de medios en SIP:
Las implementaciones de SIP varían en cuanto a si uno o ambos atributos (?a=? y ?C=IN ?) se utilizan para indicar que la secuencia de medios está inhabilitada.
Esta imagen ilustra cómo se inhabilita la secuencia de medios en el H.323:
Conexión a MoH
El segundo paso en el proceso de dos pasos mencionado anteriormente es conectar con MoH. Una vez que la secuencia de audio está inhabilitada, CUCM señala la conversación de MoH unidireccional que hace que el holdee escuche la fuente de MoH.
Como parte de este proceso, CUCM tiene en cuenta las capacidades de medios del titular y la lista de grupos de recursos de medios (MRGL) asociada al tronco antes de determinar los parámetros para la transmisión. En consecuencia, la señalización para esto siempre es Oferta demorada (DO)[2] (en SIP).
El número real de transacciones INVITE varía. Por ejemplo, CUCM conecta a los titulares con MoH con sólo una transacción DO INVITE. Alternativamente, el DO INVITE se utiliza para reunir las capacidades de los medios del titular, y se utiliza un OE INVITE subsiguiente para conectar realmente el titular al MoH.
Esta imagen ilustra la transacción para SIP:
Esta imagen ilustra la transacción para H.323:
Esta imagen ilustra la secuencia de mensajes de señalización en un entorno de interconexión (cuando un lado de CUBE es SIP y el otro lado H.323, por ejemplo):
Cuando se utilizan recursos de medios en una llamada
Los recursos de medios (MediaTermination Point (MTP) / Transcoders) protegen el tramo de llamada de CUBE a proveedor de servicios de TI (ITSP) en su mayor parte. Cuando se utiliza un recurso de medios en una llamada a través de CUBE, la señalización de MoH implica principalmente mensajes SCCP (Skinny Client Control Protocol) entre CUCM y el recurso de medios. Observe que es el recurso de medios que se pone en espera, no el troncal CUBE. Después de que el MTP/Transcodificador se haya indicado para escuchar MoH (suponiendo SIP), CUCM envía un mensaje SIP UPDATE a CUBE. Esto actualiza el parámetro bifurcación, que identifica la nueva transacción (la conversación MOH).
Reanudar la llamada
El proceso de reanudación es similar al proceso de espera, excepto que el pedido se revierte:
- La secuencia de audio actual está desactivada.
- Se envía otro DO re-INVITE para volver a conectar el retenedor al teléfono que puso la llamada en espera.
Atributo SDP
El atributo X-cisco-media:umoh en el protocolo de descripción de sesión (SDP) se introdujo para simplificar la señalización MoH sobre troncales entre clústeres (ICT)[3]. Con la interoperación entre terminales que utilizan diferentes protocolos, CUCM realiza a menudo señalización incómoda e intermedia que no es intuitiva. Para evitar las conjeturas y hacer que la señalización sea explícita en el contexto, se utiliza un atributo SDP propietario, denominado X-cisco-media.
Con las versiones 8.5 y posteriores de CUCM, MoH puede [4] señalarse con este atributo establecido en Unicast Music on Hold (UMoH) o en MMoH, que elimina la dependencia de un valor de puerto falso para indicar un escenario MoH a la parte en espera.
MoH en CUBE
Con CUBE, el proceso básico sigue siendo el mismo; sin embargo, es importante considerar que [5] CUBE no transcodifica MoH hasta que Cisco IOS? Versión 15.3T. Esto significa que debe tener cuidado con los factores que influyen en la selección de códecs en el tramo CUCM-to-CUBE para que no sea necesario un transcodificador.
Consideraciones sobre los códecs
En general, varios factores afectan el códec utilizado en el tramo CUCM-to-CUBE, pero estas consideraciones se aplican a MoH:
- MoH no se puede transcodificar.[5]
- El MoH sólo suena bien con G.711.
MMoH
El MMoH conserva los recursos del sistema y el ancho de banda. La multidifusión permite que varios usuarios utilicen la misma secuencia de origen de audio para proporcionar música en espera. El MoH es deseable en cualquier red corporativa donde el ahorro de ancho de banda sea importante.
A continuación se presentan algunas preocupaciones y problemas cuando CUBE pasa el MMoH a través de Internet al ITSP:
- Alcance del tráfico multicast: Cisco utiliza el rango 239.0.0.0 a 239.255.255.255 para música multicast. Este rango se conoce como direcciones con alcance administrativo. Este bloque se considera privado, lo que significa que es utilizado por las redes empresariales y nunca debe reenviarse fuera de la empresa. Los routers de límite generalmente se configuran en consecuencia.
- Multicast sobre VPN - De forma predeterminada, la seguridad IP no soporta MoH.
Así es como CUBE soporta MMoH:
- CUBE recibe los paquetes MMoH del servidor MoH.
- Convierte los paquetes en paquetes IP de unidifusión.
- CUBE reenvía los paquetes al ITSP.
Manipulación de atributos de dirección SIP
Como se describe en RFC 3264:
"Si una descripción de sesión contiene un flujo de medios multidifusión que se muestra como recibido (enviar) solamente, significa que los participantes, incluidos el oferente y el contestador, sólo pueden recibir (enviar) en ese flujo. Esto difiere de la vista de unidifusión, donde la direccionalidad se refiere al flujo de medios entre el oferente y el contestador. Más allá de esa aclaración, la semántica de un flujo de multidifusión ofrecido es exactamente la descrita en RFC 2327 [1]"
En consecuencia, cuando CUCM envía un re-INVITE con una dirección IP multicast, establece el atributo de dirección en recvonly; sin embargo, dado que CUBE convierte los paquetes multicast en paquetes unicast, debe establecer el atributo direction para enviar solamente en el tramo con ITSP.
Esta imagen ilustra la lógica:
Manipulación de dirección
En el DO [6] re-INVITE enviado para conectar a la persona que llama ITSP con el origen MoH, CUBE envía su propia dirección IP en el campo SIP SDP C=IN. Esta es una dirección de unidifusión.
Esta imagen proporciona una vista de extremo a extremo:
Flujo desde una memoria flash
Con los gateways TDM, se consigue un ahorro adicional en el ancho de banda de la WAN mediante la transmisión de la música multicast desde el gateway. Por lo tanto, si el servidor MoH se encuentra en la sede central y el gateway se encuentra en una sucursal remota a través de una conexión WAN, el tráfico multidifusión que transporta MoH no tiene que atravesar la WAN (de la sede central a la sucursal) y utilizar un valioso ancho de banda WAN.
CUBE es un dispositivo del lado del trunk que no es capaz de transmitir MoH que se origina desde la memoria flash local o a través de cualquier interfaz TDM analógica. Todavía es posible obtener ancho de banda WAN. Esto se logra con el uso de otro router con voz habilitada en la sucursal remota como origen del flujo MMoH. Este router transmite MoH desde la memoria flash. El CUBE luego puede ser señalado para recibir esos paquetes, convertirlos y pasarlos como paquetes de unidifusión.
Transmisión desde una fuente en directo
Para transmitir desde una fuente en vivo, se debe configurar otro router porque CUBE no es un dispositivo en línea, como se discutió en la sección anterior.
Configuración de MMoH
Esta sección describe cómo configurar el MMoH en los switches compatibles con CUBE, CUCM y L3.
Configuración de MMoH en CUBE
Utilice estos comandos para configurar el MMoH en CUBE:
ccm-manager music-on-hold
ip multicast-routing
Configuración de MoH en CUCM
Siga estos pasos para configurar el MoH en CUCM:
- Habilite la capacidad de multidifusión en el origen de MoH, el servidor MoH y el grupo de recursos de medios (MRG).
- Asigne un MRGL al tronco con el MRG configurado en el paso 1.
- Configure el códec en los parámetros de servicio de aplicación de transmisión de voz IP.
Configuración de MoH en Switches Compatibles con L3
Utilice estos comandos para configurar el MMoH en los switches con capacidad para L3:
ip routing
ip multicast-routing
Cuando se utiliza MTP en una llamada
Los MTP no admiten música multicast. El titular sólo recibe aire muerto.[7]
Consideraciones de rendimiento
Todos los paquetes MMOH se conmutan por proceso en Cisco IOS. Esto está bien para implementaciones pequeñas, pero tiene un impacto significativo en el rendimiento de CUBE para instalaciones grandes.
Restricciones
Esta es una lista de restricciones con el uso de MMoH:
- CUBE debe estar en Cisco IOS Version 15.2(2)T o posterior.
- El MoH no se soporta en el AS54xx.
- El MMoH no es compatible con ISR-G1s (series 28xx y 38xx)
- Tenga en cuenta los códecs admitidos.
Troubleshoot
Utilice esta sección para resolver problemas de MMoH.
comandos show y debug
Esta es una lista de los comandos show y debug, y sus significados:
- Mostrar música de ccm-manager - Ayuda a confirmar que CUBE sabe dónde escuchar los paquetes de música 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 - Mostrar miembros ip igmp - Se utiliza para verificar si CUBE se unió correctamente al grupo multicast cuando se le indica escuchar música multicast.
- Estos tres comandos se utilizan para verificar el códec negociado, la dirección IP y los números de puerto de los extremos:
Show call active voice compact
Este es un ejemplo de salida del primer comando:
Show voip rtp conn
Show sip callsR1#show call active voice compact
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
Total call-legs: 2
236 ANS T53 g711ulaw VOIP P1003 239.176.201.1:16384
237 ORG T53 g711ulaw VOIP P919789362814 200.200.200.2:17808 - Show call active voice brief - Ejecute este comando cuando la llamada está en espera para verificar si los conteos rx/tx aumentan.
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"- Este comando CUCM CLI se utiliza para verificar rápidamente si se asigna un recurso MoH y qué tipo (unidifusión o multidifusión). Este comando no es muy útil cuando tiene varias llamadas en espera, ya que los recuentos cambian dinámicamente cuando las llamadas se ponen en espera y se reanudan.
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 - Este comando se utiliza para rastrear cómo se cambian los tramos de llamada (cuando se inhabilita el audio actual y se conecta MoH, por ejemplo), así como para verificar si CUBE se une al grupo del Protocolo de administración de grupos de Internet (IGMP) según lo indicado por CUCM.
- Debug ip packet - Este comando se utiliza como alternativa a Wireshark para las verificaciones. Sin embargo, este comando puede superar rápidamente a la CPU. Utilícelo únicamente cuando sea absolutamente necesario; desactive el registro de la consola y no lo ejecute durante más de un segundo.
Escenario 1
Síntoma: una llamada de la Red de telefonía pública conmutada (PSTN, Public Switched Telephone Network) (PSTN, Red pública de telefonía conmutada) se establece correctamente con audio bidireccional. Sin embargo, cuando el teléfono IP pone a la persona que llama PSTN en espera y luego reanuda la llamada, se obtienen resultados de audio unidireccionales: el teléfono IP escucha el audio de PSTN, pero el usuario de PSTN no puede oír el teléfono IP.
En primer lugar, asegúrese de que Require SDP Inactive Exchange for Mid-Call Media Change NO esté desactivado en el troncal SIP en cuestión [5]. Esto es lo que permite a CUCM enviar una REINVITE con a=inactivo en SDP, para romper la trayectoria de medios que existe.
Cuando la llamada se pone en espera, CUCM no envía una REINVITE con un SDP inactivo para romper la ruta de medios si la casilla de verificación Send send-receive SDP in mid-call INVITE está habilitada para el troncal SIP [8]. Esta configuración sólo se verifica para dispositivos que no pueden proporcionar una oferta completa (send-recv) después de que el modo de medios se haya configurado en inactivo.
Estas son imágenes que ilustran las casillas de verificación disponibles:
Escenario 2
Síntoma: sólo hay un tono cuando las personas que llaman se ponen en espera en lugar de en el modo de espera.
En general, esto sugiere que CUCM no asignó el MMoH.
- ¿Utilizar la clase de consulta show perf ?Cisco MOH Device? Comando CUCM CLI para verificar si el conteo MOHOutOfResources aumenta.
- Asegúrese de que multicast esté habilitado en el origen, servidor y grupo de MMoH.
Escenario 3
Síntoma: sólo se oye el aire muerto cuando se pone en espera a la persona que llama.
Asegúrese de lo siguiente:
- El ruteo de multidifusión está habilitado en el CUBE y otros routers en la trayectoria de audio.
- El ruteo IP y el ruteo multicast están habilitados en los switches L3 en la trayectoria de audio.
- El ttl (conteo de saltos) se configura en el servidor MoH en CUCM, y es lo suficientemente grande como para cubrir los saltos.
- Si se requiere un transcodificador, se asigna correctamente.
- La lista de códecs configurados en IP Voice Streaming Application soporta el códec usado para MoH.
Situación 4
Síntoma: una llamada falla en el modo de flujo continuo para llamada en espera y reanudación.
Para admitir flujo de salida, debe enviar una REINVITE o una actualización de IPIPGW; sin embargo, actualmente no se admite. Por lo tanto, no se admite el flujo de ida y vuelta con llamadas DO-EO. Si existe un requisito de flujo de llamadas de marketing, se tendrá en cuenta el soporte. El error de Cisco, SIP SS DO-EO: La llamada falla en el modo de flujo alrededor de la llamada en espera y reanudación, se marca como una mejora para su consideración en el futuro.
Información Relacionada
- Compatibilidad con música en espera multidifusión en Cisco UBE
- Preguntas frecuentes sobre CallManager Music on Hold
- Soporte Técnico y Documentación - Cisco Systems
[1] Esto puede ser confuso: ¿cómo puede tener una conversación diferente dentro de un diálogo? Bueno, en SIP, el diálogo se refiere a la etiqueta de 3 tuptos <To tag, From y Call-ID>. Este 3-tupe permanece igual durante la fase de espera.
[2] DO - Oferta retrasada.
[3] Troncal entre clústers
[4] A partir de CUCM 8.5.
[5] La transcodificación funciona para el MMoH en las versiones 15.3T y posteriores del IOS de Cisco.
[6] DO - Oferta retrasada
[7] Guía de funciones y servicios de Cisco Unified Communications Manager, versión 8.6(1)
[8] Estos son los ajustes del perfil SIP utilizado para configurar el troncal SIP.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)