Configuración de la retransmisión DTMF en CUBE

Introducción

Este documento describe el proceso para configurar la retransmisión de multifrecuencia de tono dual (DTMF) para Cisco Unified Border Element (CUBE) Enterprise. 

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas.

• Conocimiento básico de tonos DTMF
• Conocimientos básicos sobre cómo configurar y utilizar voz de Cisco® IOS (como dial-peers)
• Conocimientos básicos sobre cómo configurar y utilizar CUBE
• Conocimiento básico de la señalización utilizada por los protocolos SIP y H323
• Conocimientos básicos sobre cómo depurar protocolos VoIP como H323 y SIP

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software y hardware.

• Cisco Unified Border Element que se ejecuta en Cisco IOS.
• Cisco Unified Communications Manager 7.x o posterior.

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

 Consulte Convenciones de Consejos Técnicos de Cisco para obtener información sobre las convenciones sobre documentos.

Antecedentes

Este documento también proporciona información y comandos sobre cómo configurar, verificar y resolver problemas de retransmisión DTMF para los diferentes protocolos de gateway VoIP soportados por CUBE.

Métodos de retransmisión DTMF compatibles para CUBE

CUBE admite una amplia variedad de métodos de retransmisión DTMF para los protocolos de señalización en banda y fuera de banda (OOB) para H.323 y protocolo de inicio de sesión (SIP).

Métodos de retransmisión DTMF en banda admitidos

• DTMF de audio en banda a través de G711
• RFC2833

Métodos de retransmisión DMTF fuera de banda admitidos

• H.245 alfanumérico
• Señal H.245
• NOTIFICACIÓN SIP no solicitada
• SIP KPML
• INFORMACIÓN SIP

Compatibilidad con DTMF de audio en banda mediante G711

El audio en banda de voz o DTMF G711 se refiere al transporte de tonos audibles a través de la secuencia de audio de voz, sin ninguna implicación adicional del protocolo de señalización o del DSP para su transmisión que no sea configurar la llamada normalmente y pasar el audio de extremo a extremo y utilizar el códec G711Ulaw/Alaw. Esto significa que el IOS de CUBE/Cisco sólo pasa el audio de los tonos que vienen de un extremo al otro como si fuera audio de voz normal. La medida importante que se debe tomar para este método es garantizar que las llamadas se establecen y utilizan el códec G711Ulaw/Alaw específicamente porque el uso de un códec que comprima el audio (cualquier otro códec que no sea G711) distorsiona los tonos DTMF y es probable que los haga irreconocibles para el extremo receptor. Esto se debe a que el algoritmo de compresión utilizado por los códecs de compresión alta fue diseñado para reconocer y predecir la voz humana y no los tonos DTMF.

El audio en banda/DTMF G711 es compatible con cualquier protocolo de señalización VoIP y solo requiere que se aplique el códec G711 para las llamadas de extremo a extremo. También se debe tener en cuenta que el cualquier tratamiento de transcodificación de un códec de baja velocidad de bits (LBR) a G711 muy probablemente distorsiona los tonos también.

Nota: Es común que surja cierta confusión cuando se habla de este método de retransmisión DTMF porque el término En banda se utiliza para referirse al transporte de DTMF dentro de la secuencia RTP llamada como Evento de Telefonía con Nombre (NTE/RFC2833) y cuando se trata de tonos de audio en banda. Siempre es importante aclarar el método real requerido/soportado para aplicar la configuración adecuada y utilizar el enfoque correcto para resolver problemas.

Métodos de retransmisión DTMF compatibles para H323 

H.245 alfanumérico

Los dígitos DTMF se separan de la secuencia de voz y se envían a través del canal de señalización OOB H.245 en lugar de enviarse a través del canal RTP. Los tonos se transportan en mensajes de indicación de entrada de usuario H.245. El canal de señalización H.245 es un canal confiable y se garantiza que los paquetes que transportan los tonos DTMF se entreguen. Todos los sistemas que son compatibles con H.323 versión 2 son necesarios para soportar el comando dtmf-relay h245-alphanumeric. Sin embargo, el soporte del comando dtmf-relay h245-signal es opcional.

Señal H.245

El método OOB, que es similar al método alfanumérico H.245, permite el paso de la información de duración del tono, por lo que soluciona un problema potencial con el método alfanumérico al interactuar con los sistemas de otros proveedores.

Eventos de telefonía con nombre (NTE): RFC2833

Este método transporta tonos DTMF en paquetes RTP separados de acuerdo con la sección 3 de RFC 2833. RFC 2833 define los formatos de los paquetes RTP de NTE utilizados para transportar dígitos DTMF, colgado flash y otros eventos de telefonía entre dos extremos de peer. Con el método NTE, los terminales realizan la negociación por llamada de los parámetros de retransmisión DTMF para determinar el valor del tipo de carga útil para los paquetes NTE RTP y los eventos de dígitos NTE admitidos. Como resultado, los tonos DTMF se comunican a través de paquetes RTP con un valor de tipo de carga útil diferente de los valores negociados para otros paquetes de medios; que proporciona un método confiable para transportar los dígitos y evitar que no se reconozcan cuando se comprimen a través del códec utilizado para codificar el tráfico de voz, video o fax.

El relé DTMF RFC2833/NTE se considera un método en banda porque los dígitos se transportan dentro del propio tráfico de audio RTP sin ninguna participación del protocolo de señalización GW.

Es importante señalar que el método RFC2833/NTE no debe confundirse con el audio en banda de voz o el flujo RTP G711, ya que el último es solo los tonos audibles que se transmiten como audio normal sin que ningún método de señalización de relé sea consciente o esté involucrado en el proceso. Esto significa que son solo tonos de audio simples que se transmiten de extremo a extremo utilizando el códec G711Ulaw/Alaw.

Otros datos sobre NTE con H323:

• H.323 admite RFC2833 a partir de V4
• Cisco IOS siempre anuncia su compatibilidad con 2833 en TCS
• CUCM solo admite NTE a través de una ICT H.323.

RTP propiedad de Cisco

Con este método, los tonos DTMF se envían en el mismo canal RTP que los datos de voz. Sin embargo, los tonos DTMF se codifican de forma diferente a las muestras de voz y se identifican como de tipo de carga útil 121, lo que permite al receptor identificarlos como tonos DTMF. CUCM no admite este método y su uso se ha interrumpido.

Métodos de retransmisión DTMF compatibles para SIP

NTE: RFC2833

Los atributos y tipos de carga útil de NTE RFC2833 en banda se negocian entre los dos extremos de la configuración de llamada que utilizan el protocolo de descripción de sesión (SDP) dentro de la sección de cuerpo del mensaje SIP.

NOTIFICACIÓN no solicitada (ONU)

Con este método, los dígitos se envían OOB como mensajes SIP NOTIFY dentro de la carga útil del cuerpo del mensaje.

Lenguaje de marcado de teclas (KPML)

Basado en RFC4730, los dígitos se transportan OOB usando XML dentro de los mensajes Subscribe/NOTIFY. Se utiliza principalmente para terminales SIP registrados en CUCM o CME, pero también con ITSP.

Información (INFO)

Los dígitos se transmiten como mensajes OOB SIP INFO entre los extremos. Este método no requiere ninguna configuración y CUBE lo acepta y relaciona automáticamente.

Nota: Unified CM no admite SIP INFO.

Nota: Cuando se negocian los métodos UN y NTE, Cisco IOS siempre elige UN sobre NTE para evitar los tonos dobles y se suprime el paquete NTE en banda 2833. Además, para CUCM, se utiliza UN solo cuando no hay otra opción disponible. Del mismo modo, si tanto KPML como UN están presentes, Cisco Call Manager (CCM) elige KPML en lugar de UN.

Configuración de DTMF-Relay en CUBE

De forma predeterminada, la retransmisión DTMF se inhabilita para los pares de marcado H323 y SIP (excepto para SIP INFO); es obligatorio configurar el método de retransmisión DTMF para que se utilice de extremo a extremo en los pares de marcado entrantes y salientes para cada tramo de llamada.

Configuración de DTMF Relay para H323

Router(config)#dial-peer voice 1 voip
Router(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833

Puede configurar más de un método por par de marcado, dependiendo de los requisitos de los extremos de terminación.

Router(config-dial-peer)#dtmf-relay rtp-nte ?
  cisco-rtp          Cisco Proprietary RTP
  digit-drop         Digits to be passed out-of-band and in-band digits dropped
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE

Configuración de la retransmisión DTMF para SIP

Router(config)#dial-peer voice 1 voip
Router(config-dial-peer)#dtmf-relay ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833
  sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY 
  sip-NOTIFY         DTMF Relay via SIP NOTIFY  messages

 Puede configurar más de un método por par de marcado, dependiendo de los requisitos de los extremos de terminación.

Router(config-dial-peer)#dtmf-relay rtp-nte ?
  cisco-rtp          Cisco Proprietary RTP
  digit-drop         Digits to be passed out-of-band and in-band digits dropped
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  sip-kpml           DTMF Relay via KPML over SIP SUBSCRIBE/NOTIFY 
  sip-NOTIFY          DTMF Relay via SIP NOTIFY  messages

Nota: Agregue el comando session protocol sip en dial-peer para que las opciones de dtmf-relay SIP estén disponibles.

Configuración de DTMF Relay Digit-Drop

Para evitar dígitos duplicados al retransmitir los mismos dígitos DTMF a través de los métodos en banda y fuera de banda al tramo saliente para las llamadas que interactúan desde una banda dentro (RTP-NTE específicamente) a un método fuera de banda, configure el comando dtmf-relay rtp-nte digit-drop en el dial-peer entrante y el método fuera de banda deseado en el dial-peer saliente. De lo contrario, el mismo dígito se envía en OOB así como en banda y se interpreta como dígitos duplicados por el extremo receptor.

Cuando la opción de descarte de dígitos se configura en el tramo entrante, CUBE suprime los paquetes NTE y sólo retransmite los dígitos que utilizan el método OOB configurado en el tramo saliente.

Como se muestra en esta imagen, la opción de descarte de dígitos sólo está disponible cuando interactúa entre estos métodos de retransmisión DTMF.

Por ejemplo, configure el comando dtmf-relay rtp-nte digit-drop en el dial-peer entrante para un tramo SIP que envía dígitos a través de RFC2833, y luego en el lado H.323 saliente configure dtmf-relay h245-alphanumeric o dtmf-relay h245-signal; esto debe dar lugar a que CUBE suprima los paquetes NTE y envíe solamente los eventos H245 OOB en su lugar.

Para obtener más información, consulte DTMF Relay Digit Drop.

Validar y solucionar problemas de retransmisión DTMF

Validar OOB DTMF Relay para H323

Anuncio de capacidad alfanumérica H.245

Para validar si un terminal anuncia la capacidad alfanumérica H.245, busque esta línea dentro del mensaje de conjunto de capacidades de terminal (TCS) H.245 usando debug h245 asn1.

capability receiveUserInputCapability : basicString : NULL

Ejemplo de transmisión alfanumérica H.245

Este es un ejemplo de un punto final que transmite el dígito 1 usando el método alfanumérico H245 usando debug h245 asn1.

000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::=
	value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“ 

Anuncio de capacidad de señal H.245

Para confirmar si un terminal está anunciando la capacidad de la señal H.245, busque esta línea dentro del mensaje del conjunto de capacidades del terminal (TCS) H.245 que utiliza debug h245 asn1.

capability receiveUserInputCapability : dtmf : NULL

Ejemplo de transmisión de señal H.245

Este es un ejemplo de un punto final que transmite el dígito 1 con una duración de 100 mseg utilizando el método de señal H245. Hay dos mensajes, el primer mensaje indica el dígito que se está marcando con una duración de 4s. Sin embargo, la segunda señal (signalUpdate) actualiza el valor de duración del dígito a 100 mseg.

000555: Sep 28 19:12:05.364: H245 MSC OUTGOING PDU ::=
		 value MultimediaSystemControlMessage ::= indication : userInput : signal :
		    {
		      signalType "1"
		      duration 4000
		    }
000558: Sep 28 19:12:05.368: H245 MSC OUTGOING PDU ::=
		 value MultimediaSystemControlMessage ::= indication : userInput : signalUpdate :
		    {
		       duration 100
		       rtp
		      { 
                        logicalChannelNumber 2
		      }

Confirmar la retransmisión DTMF en banda para H323

Los terminales que tienen H.323 V5 pueden indicar que admiten RFC2833 a través de un mensaje de capacidad dentro del mensaje TerminalCapabilitySet (TCS).

RFC2833 Anuncio de compatibilidad de funciones

Para confirmar si un terminal está anunciando la capacidad RFC2833, busque esta estructura dentro del mensaje TCS H.245 que utiliza debug h245 asn1 (en el ejemplo, el tipo de carga útil 101 se está anunciando para los eventos del 0 al 16).

capabilityTableEntryNumber 34
          capability receiveRTPAudioTelephonyEventCapability :
          {
            dynamicRTPPayloadType 101
            audioTelephoneEvent "0-16"
          }

Validar OOB DTMF Relay para SIP

Ejemplo de anuncio de NOTIFY no solicitado (UN)

Para confirmar si un terminal anuncia la función de notificación no solicitada (UN), busque esta línea dentro del mensaje INVITE y/o los mensajes de respuesta a INVITE mediante los mensajes debug ccsip.

INVITE sip:9999@192.168.106.66:5060 SIP/2.0
	Call-Info: <sip:192.168.106.50:5060>;method="NOTIFY ;Event=telephone-event;Duration=2000“

Ejemplo de transmisión de NOTIFY no solicitado (UN)

El método UN transmite los dígitos como datos binarios dentro del mensaje NTFY; por lo tanto, no puede ver qué dígito se transporta mediante los mensajes debug ccsip. Puede necesitar una captura de paquetes (PCAP) o tener que ejecutar el comando debug ccsip all para ver el dígito dentro de las salidas de datos binarios.

Ejemplo de cómo se vería el mismo dígito 7 marcado al ejecutar el comando debug ccsip all.

001738: Oct  9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/sipDisplayBinaryData:
 Sending: Binary Message Body
001739: Oct  9 15:37:24.577: Content-Type: audio/telephone-event
07 00 07 D0

001756: Oct  9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
NOTIFY sip:9999@192.168.106.66:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C
From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE
To: <sip:9999@192.168.106.66>;tag=cuecebad539
Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1
CSeq: 106 NOTIFY
Event: telephone-event
Subscription-State: active
Contact: <sip:192.168.106.50:5060>
Content-Type: audio/telephone-event
Content-Length: 4

001763: Oct  9 15:37:24.593: //0/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C
To: <sip:9999@192.168.106.66>;tag=cuecebad539
From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE
Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1
CSeq: 106 NOTIFY
Content-Length: 0
Allow-Events: refer
Allow-Events: telephone-event
Allow-Events: message-summary

Lenguaje de marcado de pulsaciones de teclas (KPML) AEjemplo de anuncio

La función KPML aparece en el encabezado SIP Allow-Events. Para las transmisiones de dígitos KPML, el terminal transmisor primero debe enviar una suscripción al servicio KPML; se transmite el mensaje SUBSCRIBE que solicita la capacidad; seguido de un mensaje NOTIFY del extremo receptor que marca el estado de suscripción para los eventos KPML como activos.

Invitación inicial para anunciar la función.

INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 
Allow-Events: kpml, telephone-event

El extremo de terminación solicita la suscripción a los eventos KMPL.

SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0
Event: kpml 
Content-Type: application/kpml-request+xml 

El extremo de origen responde con un mensaje NOTIFY que establece el estado como activo.

NOTIFY  sip:192.168.105.25:5060 SIP/2.0
Event: kpml 
Subscription-State: active

KPML TEjemplo de transmisión

Una vez que se ha realizado la suscripción, los terminales pueden transmitir los dígitos mediante mensajes NOTIFY con eventos KPML mediante XML. Ejemplo de dígito 1 transmitido.

NOTIFY  sip:192.168.105.25:5060 SIP/2.0
Event: kpml 
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/> 

Interconexión DTMF

CUBE admite alrededor de 30 tipos diferentes de interconexión DTMF. Es capaz de interactuar y transcodificar entre diferentes métodos de relay basados en el comando dtmf-relay configurado dentro de los pares de marcado entrantes y salientes coincidentes para la llamada.

Refiérase a la sección Tabla de Interoperabilidad DTMF de la Guía de Configuración de CUBE para obtener detalles sobre el Soporte de Interconexión DTMF. 

¿Cuándo requiere CUBE recursos de transcodificación para DTMF?

CUBE requiere la transcodificación de recursos registrados localmente en estos escenarios

• Interconexión entre RFC2833 y voz en banda
• Interconexión entre un método OOB y RFC2833 para llamadas de flujo alrededor

CUBE puede interactuar entre todos los demás métodos de retransmisión DTMF con llamadas de flujo de entrada sin necesidad de un transcodificador.

Interconexión DTMF entre Inband G711 y RFC2833

CUBE puede interactuar entre DTMF Inband G711 (tonos de audio sin formato) y RFC2833. Sin embargo, estos requisitos deben cumplirse

• El códec utilizado debe ser G711 de extremo a extremo. Esto es una restricción porque si se utilizara un códec LBR, los tonos se distorsionarían debido a la pérdida de compresión.
• Los recursos de transcodificación deben estar disponibles y registrados con el CUBE según corresponda. Esto se debe a que el CUBE necesita asignar un recurso de transcodificación (más específicamente: un recurso DSP) a la secuencia RTP de medios para insertar o escuchar los tonos dentro de la secuencia de audio.
• El dial-peer para el tramo de tonos dentro de la banda no debe tener ningún comando de retransmisión DTMF configurado. Este requisito ya no es necesario para IOS XE 16.12.x o posterior. CUBE puede asignar dinámicamente un transcodificador incluso si el par de marcado ITSP/entrante tiene configurado dtmf-relay rtp-nte. La decisión de asignar un transcodificador puede depender de la negociación SDP entre los dispositivos pares.
• El par de marcado para el tramo RFC2833 debe tener configurado dtmf-relay rtp-nte.
• No habilite el descarte de dígitos en ninguno de los pares de marcado involucrados con la llamada.

Otras opciones de interconexión DTMF

También existe un conjunto adicional de comandos de interconexión que podrían ser necesarios en escenarios de llamadas específicos; que se pueden configurar globalmente o en el nivel de par de marcado.

dtmf-interworking {rtp-nte | standard | system} 
	rtp-nte	Enables a delay between the dtmf-digit begin and dtmf-digit end events of RTP NTE packets. 
	Standard	Generates RTP NTE packets that are RFC 4733 compliant. 
	System	Specifies the default global DTMF interworking configuration. This keyword is available only in dial peer voice configuration mode.

Cuándo requieren CUCM recursos de MTP

El recurso MTP se hace necesario cuando CUCM necesita interconectar diferentes métodos DTMF entre dos dispositivos, uno de ellos usando el método RFC2833 específicamente y el otro un método OOB. En esta situación, CUCM necesita asignar los recursos necesarios para transmitir o detectar los tonos en banda debido a la discordancia de retransmisión DTMF entre los dos extremos.

La función del MTP es monitorear el tráfico RTP y detectar los eventos NTE del tramo RFC2833 o inyectar los eventos NTE en el flujo RTP si lo solicita CUCM. Si el MTP detecta eventos NTE entrantes del punto final que sólo admiten RFC2833, envía un mensaje SCCP StationNOTIFYDtmfToneMessage al CUCM y le informa del tono detectado en la secuencia. A su vez, CUCM envía el mismo dígito y utiliza el protocolo de señalización (OOB) al otro extremo. Si CUCM recibe una señal OOB DTMF del punto final OOB DTMF, envía un mensaje SCCP StationSendDtmfToneMessage al MTP para que el MTP pueda inyectar el tono solicitado en la secuencia RTP en forma de eventos NTE.

Dispositivos MTP admitidos por CUCM

Software MTP (Cisco IP Voice Media Streaming Application)

Software MTP es un dispositivo que se implementa habilitando Cisco IP Voice Media Streaming Application en un servidor CUCM. Cuando la aplicación instalada se configura como una aplicación MTP, se registra con un nodo de CUCM e informa a CUCM de cuántos recursos MTP admite. Un dispositivo MTP de software sólo admite secuencias G.711. La configuración predeterminada de CUCM le permite manejar hasta 48 llamadas según el MTP del software. Para obtener más información sobre cómo modificar los parámetros de servicio, consulte la versión correspondiente de la Guía de administración de Cisco Unified Communications Manager.

MTP de software (basado en Cisco IOS)

Este MTP permite la configuración de cualquiera de estos códecs; sin embargo, solo se puede configurar uno en un momento dado: G.711 mu-law y a-law, G.729a, G.729, G.729ab, G.729b y passthrough. Algunas de estas opciones no son pertinentes para una implementación de CUCM.

Las configuraciones de router permiten hasta 1000 flujos individuales, que admiten 500 sesiones transcodificadas que generan 10 Mbytes de tráfico. Los routers Cisco ISR G2 y ASR pueden admitir un número considerablemente mayor que este.

Este MTP consume ciclos de CPU para funcionar. Anote el número de sesiones habilitadas, ya que podría afectar al rendimiento de la CPU y provocar un uso elevado de la CPU.

Hardware MTP (PVDM2, Cisco NM-HDV2 y NM-HD-1V/2V/2VE)

Este hardware utiliza los módulos PVDM-2 para proporcionar DSP.

MTP de hardware (routers de las series 2900 y 3900 de Cisco con PVDM3)

Estos routers utilizan los DSP PVDM3 de forma nativa en las placas base o PVDM2 con un adaptador en la placa base o en los módulos de servicio.

Nota: No puede configurar G.729 o G.729b al configurar los recursos MTP de hardware en Cisco IOS. Sin embargo, Unified CM puede utilizar los recursos de transcodificación de hardware como MTP si todos los demás recursos MTP se han agotado o no están disponibles.

Cuándo Utilizar MTP de Software o Hardware

El tipo de MTP que se implementará en la red depende de los parámetros de códec específicos admitidos por los terminales, gateways y trunks en el flujo de llamadas

• Los sabores del códec que se utilizarán
• El tamaño de paquete de códec que se va a utilizar (empaquetamiento)
• Uso de fax T.38 (requiere compatibilidad con paso a través de códec)

Según estos parámetros, puede elegir e implementar con seguridad los recursos adecuados que necesita su red.

Como se muestra en la tabla, las diferentes funciones soportadas por los diferentes tipos de MTP y transcodificador

Tipo	Mismos códecs	Códecs diferentes	Paquetes diferentes	Códec Transferencia	Notas
CUCM SW MTP	Yes	No	Yes	No	Transcodificación y reempaquetamiento de G711 Alaw-Ulaw
MTP de HW de Cisco IOS	Yes	No	No	Yes	Compatibilidad con cualquier códec (y el mismo sabor), siempre y cuando se utilice el mismo paquete. Sin transcodificación.
MTP de SW de Cisco IOS	Yes	No	No	Yes	Admita cualquier códec (y el mismo sabor) siempre que se incluya el mismo paquete. Sin transcodificación.
Cisco IOS Regular Xcoder	Yes	Yes	Yes	Yes	Siempre y cuando al menos un lado sea G711u/G711a, soporta cualquier reempaquetado y transcodificación.
Cisco IOS Universal Xcoder	Yes	Yes	Yes	Yes	Soporte en cualquier códec, empaquetamiento y transcodificación.

Para obtener más información sobre la configuración de MTP en CUCM, consulte el Ejemplo de Configuración del Punto de Terminación de Medios .

Consideraciones sobre el grupo de recursos de medios (MRG) de CUCM y la lista de grupos de recursos de medios (MRGL) para MTP

Al crear y asignar recursos de medios a grupos de recursos de medios (MRG) y listas de grupos de recursos de medios (MRGL), tenga en cuenta algunos puntos adicionales para evitar la suscripción excesiva de los mejores recursos para flujos de llamadas específicos y priorícelos en consecuencia. CUCM no puede seleccionar el mejor dispositivo para usar, cuando selecciona un recurso multimedia para una llamada, de una lista dada de MTP y transcodificadores si tienen la misma prioridad o orden. En su lugar, elige el primer dispositivo que admite las capacidades solicitadas. Por lo tanto, incluso si la llamada utiliza G711 en ambos tramos, si el primer dispositivo que encuentra es un transcodificador, lo asigna como un MTP para la llamada y no busca un recurso MTP más adelante en la lista.

Otro comportamiento similar ocurre cuando tiene transcodificadores universales y regulares. CUCM podría utilizar los transcodificadores normales primero en una llamada en la que uno de los tramos era G711 y luego fallar cuando una llamada se transfiere a un destino que utiliza un códec no G711, porque CUCM no va a liberar el transcodificador actual y obtener otro cuando se transfiere la llamada.

La mejor práctica de diseño para sortear este comportamiento es asignar todos los dispositivos MTP solamente en un solo MRG, luego los transcodificadores universales a otro MRG y los transcodificadores regulares a un tercer MRG; y luego priorizarlos en el mismo orden dentro del MRGL. Ahora, este diseño no puede funcionar para todas las topologías y debe revisarse caso por caso.

Mensajes SCCP MTP

Estos mensajes SCCP se intercambian entre los recursos de CUCM y MTP para la gestión de DTMF.

•  StationCapabilitiesRes
•  StationUpdateCapabilities
•  StationSubscribeDtmfPayloadReq
•  StationSubscribeDTMFPayloadErrv
•  StationSubscribeDtmfPayloadRes
•  StationUnsubscribeDtmfPayloadErr
•  StationNOTIFYDtmfToneMessage
•  StationSendDtmfToneMessage
•  StationUnsubscribeDtmfPayloadReq
•  StationUnsubscribeDtmfPayloadRes

Retransmisión DTMF entre CUCM y CUBE

Troncal SIP de CUCM a CUBE

CUBE admite KPML, NTE o Unsolicited Notify como mecanismo DTMF, en función de su configuración. Dado que puede haber una mezcla de terminales en el sistema, se pueden configurar varios métodos en el CUBE simultáneamente para minimizar los requisitos de MTP.

En CUBE, configure sip-kpml y rtp-net como métodos de retransmisión DTMF en pares de marcado SIP. Esta configuración permite el intercambio DTMF con todos los tipos de terminales, incluidos aquellos que sólo admiten NTE y aquellos que sólo admiten métodos OOB, sin la necesidad de recursos MTP. Con esta configuración, el gateway negocia tanto NTE como KPML con CUCM. Si el terminal de Unified CM no admite NTE, se utiliza KPML para el intercambio DTMF. Si ambos métodos se negocian correctamente, la puerta de enlace depende de NTE para recibir dígitos y no se suscribe a KPML.

CUBE también puede utilizar el método de notificación no solicitada (UN) para DTMF. El método UN envía un mensaje de notificación SIP con un cuerpo que contiene texto que describe el tono DTMF. Este método también es compatible con Unified CM y se puede utilizar si sip-kpml no está disponible. Configure sip-notify como el método de retransmisión DTMF. Observe que este método es propiedad de Cisco.

Los CUBE configurados solo para la retransmisión NTE o que, debido a alguna limitación de interconexión, solo pueden proporcionar recursos NTE y MTP requeridos para ser asignados en el lado de CUCM cuando se comunican con extremos que no admiten NTE.

Puede encontrar más información sobre los requisitos de MTP troncal SIP de CUCM

Troncal CUCM H323 a CUBE

CUCM elige dinámicamente el método de transporte DTMF para los troncales H323; por lo tanto, no hay opciones configurables para elegir uno sobre el otro. Si desea forzar un método de retransmisión DTMF específico, puede hacerlo desde la configuración de dial-peer CUBE para este trunk.

Incluso cuando los CUBE H323 admiten NTE, no se debe utilizar la opción NTE porque no es compatible con CUCM para gateways/troncales H.323 en este momento; por lo tanto, CUCM no anuncia esta capacidad en el momento en que se intercambian las capacidades de medios H245. La opción preferida de CUCM es la señal H.245.

Los recursos MTP son necesarios para establecer llamadas a un CUBE H.323 si el otro terminal no tiene capacidad de señalización en común con CUCM. Por ejemplo, un teléfono IP 7960 de Cisco Unified que ejecute la pila SIP admite solo NTE, por lo que se necesita un MTP con un enlace troncal H.323 para que se pueda utilizar H245 Alphanumeric en el segmento H323.

Carga dinámica/asimétrica de CUBE

A partir de la versión 15.1(1)T (CUBE 1.4) de Cisco IOS, se introdujo el soporte para Dynamic Payload Type Interworking para DTMF y Paquetes de Códec para Llamadas SIP a SIP.

Esta función permite que CUBE gestione la interconexión de: tipos de carga útil dinámica para códecs de audio/vídeo, NSE y DTMF; que hasta este momento estaba limitada porque el IOS de Cisco reservaría un rango estático y solo permitiría que se negociaran los mismos tipos de carga útil en ambos tramos de llamada y rechazaría la llamada con una respuesta de error 488 para códecs de audio/vídeo/NSE no coincidentes (o de reserva para DTMF G711 de voz dentro de banda) para cargas útiles NTE no coincidentes. Por lo tanto, la función permite que el CUBE anule la reserva o libere tipos de carga dinámicamente para la interacción con proveedores SIP o dispositivos de terceros que utilizan una gama diferente de tipos de carga a otro segmento que no los admitiría o que requiere una asignación diferente específicamente.

Un segmento de llamada en CUBE se considera simétrico o asimétrico en función del valor del tipo de carga útil intercambiada a través de SDP durante la oferta y la respuesta con el terminal.

• Un punto final simétrico acepta y envía el mismo tipo de carga útil para eventos NTE o un códec específico para un segmento de llamada.
• Un terminal asimétrico puede aceptar y enviar diferentes tipos de carga útil para eventos NTE o un códec específico para un tramo de llamada.

Este comando está disponible para especificar el uso de cargas útiles asimétricas; el comando se puede aplicar globalmente en el modo de configuración voice service voip enter sip o en el nivel de par de marcado mediante la CLI voice-class sip

asymmetric payload {dtmf | dynamic-codecs | full | system}

Para obtener más información sobre las cargas útiles dinámicas/asimétricas, navegue hasta Interconexión de tipo de carga útil dinámica para DTMF y paquetes de códec para llamadas SIP a SIP

Ejemplo de cargas útiles simétricas

A continuación se muestra un ejemplo de cómo se vería el SDP para una negociación de carga útil simétrica y el resultado de la sesión debug voip rtp denominada event mientras se transmiten los tonos DTMF. Tenga en cuenta que la configuración utilizada para forzar el IOS de Cisco puede utilizar un tipo de carga útil diferente para los eventos NTE que utilizan el comando rtp payload-type nte.

Negociación de retransmisión DTMF

Transmisión de relé DTMF

Ejemplo de Payloads Asimétricos

A continuación se muestra un ejemplo de cómo se vería el SDP para una negociación de carga útil asimétrica y el resultado del comando debug voip rtp session named event mientras se transmiten los tonos DTMF. Tenga en cuenta la configuración utilizada para forzar al IOS de Cisco a utilizar un tipo de carga útil diferente para los eventos NTE y utiliza los comandos rtp payload-type nte y voice-class sip asymmetric payload dtmf CLI.

Negociación de retransmisión DTMF

Transmisión de relé DTMF

Qué método de retransmisión DTMF se debe utilizar

 Al elegir el DTMF-relay a utilizar, debe tener en cuenta estas variables.

• Dispositivos y plataformas implicados.
• Protocolos VoIP involucrados.
• Ruta de medios y códecs compatibles.
• Métodos de retransmisión DTMF admitidos o preferidos.

Métodos de retransmisión DTMF preferidos para H.323

El método preferido para H323 sería utilizar OOB a través de H.245 alfanumérico o señal en casi todos los escenarios. También puede utilizar RFC2833 siempre y cuando CUCM no esté involucrado.

Métodos de retransmisión DTMF preferidos para SIP

• Líneas troncales SIP para proveedores de servicios: siempre que haya un enlace troncal SIP con un proveedor SIP implicado o interacción con 3^rd dispositivos SIP de terceros o sistemas IVR; se prefiere utilizar en banda mediante RFC2833.
• Troncal SIP a CUCM o CME: habilite RFC2833 y KPML.
• Troncal SIP a CUE: el método predeterminado para CUE es UN, pero también puede configurarlo para usar NTE; que también es la mejor opción si la llamada proviene de un proveedor SIP al sistema CUE.

Información Relacionada

Compatibilidad con transcodificación de voz universal para gateways de IP a IP

Conversión DTMF

Ejemplo de Configuración de Unified Border Element Transcoding

Uso de Cisco Unified Communications Manager para configurar la transcodificación y el punto de terminación de medios

Configuración de DTMF Relay Digit-Drop en un Cisco Unified Border Element

Requisitos de MTP de troncal SIP

Método SIP INFO para la generación de tono DTMF

Enlaces troncales H.323 con puntos de terminación de medios

Interfaz de transcodificación local (LTI) de CUBE 9.0