El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe problemas comunes que pueden ocurrir en conversaciones de audio unidireccionales de telefonía IP que involucran gateways de Cisco.
Cisco recomienda que tenga conocimiento sobre estos temas:
Este documento no se limita a una versión específica de software o 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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Este documento proporciona escenarios y soluciones para estos problemas:
Cuando se establece una llamada telefónica desde una estación IP a través de un gateway o router de voz del IOS de Cisco, sólo una de las partes recibe audio (comunicación unidireccional).
Cuando se establece una llamada de omisión de llamada entre dos gateways de Cisco, solo uno de los interlocutores recibe audio (comunicación unidireccional).
Cuando se establece una llamada telefónica desde una estación IP que se coloca detrás de un cliente de hardware VPN 3002, sólo uno de los interlocutores recibe audio (comunicación unidireccional).
Las causas del audio unidireccional en la telefonía IP pueden ser variadas, pero la raíz del problema generalmente involucra problemas de IP Routing. En esta sección se analizan algunos de los escenarios y soluciones que se han encontrado sobre el terreno.
Algunos gateways de Cisco IOS, como el VG200, desactivan el routing IP de forma predeterminada. Esta configuración predeterminada provoca problemas de voz unidireccionales.
Nota: Antes de continuar, asegúrese de que el enrutamiento IP esté activado en el router. En otras palabras, asegúrese de que su router no tenga el comando de configuración global no ip routing.
Para habilitar el ruteo IP, ejecute este comando de configuración global en su gateway de Cisco IOS:
voice-ios-gwy(config)#ip routing
Compruebe siempre primero la disponibilidad básica de IP. Dado que los flujos del protocolo de transporte en tiempo real (RTP) no tienen conexión (se transportan a través de UDP), el tráfico puede desplazarse correctamente en una dirección pero perderse en la dirección opuesta. Este diagrama muestra un escenario en el que esto puede suceder:
Las subredes A y B pueden alcanzar la subred X. La subred X puede alcanzar las subredes A y B. Esto permite el establecimiento de conexiones TCP entre las estaciones finales (A y B) y Cisco CallManager. Por lo tanto, la señalización puede llegar a ambas estaciones finales sin ningún problema, lo que permite el establecimiento de llamadas entre A y B.
Una vez que se establece una llamada, una secuencia RTP que transporta el audio debe fluir en ambas direcciones entre las estaciones finales. En algunos casos, la subred B puede alcanzar la subred A, pero la subred A no puede alcanzar la subred B. Por lo tanto, la secuencia de audio de A a B siempre se pierde.
Este es un problema de ruteo básico. Utilice los métodos de resolución de problemas de ruteo IP para llegar a la etapa en la que puede hacer ping exitosamente al Teléfono A desde la Puerta de enlace B. Recuerde que el ping es una verificación bidireccional.
Este documento no cubre la resolución de problemas de ruteo IP. Sin embargo, asegúrese de que estos son los siguientes pasos:
Las puertas de enlace predeterminadas se configuran en las estaciones finales.
Las rutas IP de esos gateways predeterminados conducen a las redes de destino.
Esta lista explica cómo verificar la configuración predeterminada del router o la gateway en varios teléfonos IP de Cisco:
Cisco IP Phone 7910: pulse Settings, seleccione la opción 6 y baje el volumen hasta que aparezca el campo Default Router (Router predeterminado).
Cisco IP Phone 7960/40: pulse Settings, seleccione la opción 3 y desplácese hacia abajo hasta que aparezca el campo Default Router (Router predeterminado).
Cisco IP Phone 2sp+/30vip: Pulse **# y, a continuación, pulse # hasta que aparezca gtwy=.
Nota: cuando utilice la aplicación Cisco IP SoftPhone y haya más de una tarjeta de interfaz de red (NIC) instalada en el dispositivo, asegúrese de que éste obtenga la NIC correcta. Este problema se presenta comúnmente en la versión 1.1.x del software IP SoftPhone. La versión 1.2 debe resolver este problema.
Nota: Cuando utilice gateways DT-24+ de Cisco, verifique el alcance DHCP y asegúrese de que haya una opción Default Gateway (router 003) en el alcance. El parámetro de router 003 rellena el campo Default Gateway (Puerta de enlace predeterminada) en los dispositivos y PC. La opción de ámbito 3 debe tener la dirección IP de la interfaz del router que puede enrutar para la puerta de enlace.
Si se configura la transcodificación para un troncal de interclúster (ICT), asegúrese de que se haya configurado un punto de terminación de medios (MTP) en el grupo de recursos de medios y en la lista de grupos de recursos de medios asociados al troncal. Si especifica un MTP cuando no se necesita uno, o no puede configurar un MTP si es necesario, se sabe que causa problemas de voz unidireccional para las configuraciones de ICT.
Cuando el gateway de Cisco IOS tiene varias interfaces IP activas, parte de la señalización H.323 se puede originar en una dirección IP y otras partes de ella pueden hacer referencia a una dirección de origen diferente. Esto puede generar varios tipos de problemas. Uno de estos problemas es el audio unidireccional.
Para evitar este problema, puede vincular la señalización H.323 a una dirección de origen específica. La dirección de origen puede pertenecer a una interfaz física o virtual (bucle invertido). Utilice el comando h323-gateway voip bind srcaddr ip-address en el modo de configuración de la interfaz. Configure este comando en la interfaz con la dirección IP a la que apunta Cisco CallManager.
Este comando se introdujo en Cisco IOS Software Release 12.1(2)T. Consulte Soporte H.323 para Interfaces Virtuales.
Precaución: existe un error en Cisco IOS Software Release 12.2(6) en el cual esta solución puede causar realmente un problema de audio unidireccional. Para obtener más información, consulte el ID de bug de Cisco CSCdw69681. Solo los usuarios registrados de Cisco pueden acceder a la información y las herramientas internas de Cisco.
La voz unidireccional puede producirse en las puertas de enlace del protocolo de control de gateway de medios (MGCP) si no se especifica la interfaz de origen para los paquetes de medios y de señalización. Puede enlazar el medio MGCP a la interfaz de origen si emite el comando mgcp bind media source-interface interface-id y luego el comando mgcp bind control source-interface interface-id comando. Reinicie el gateway MGCP en Cisco CallManager después de ejecutar los comandos.
Si el comando mgcp bind no está habilitado, la capa IP sigue proporcionando la mejor dirección local.
Las pautas para el comando mgcp bind son:
Cuando hay llamadas MGCP activas en el gateway, se rechaza el comando mgcp bind tanto para el control como para los medios.
Si la interfaz de enlace no está activa, el comando se acepta pero no surte efecto hasta que la interfaz se activa.
Si la dirección IP no se asigna en la interfaz de enlace, el comando mgcp bind se acepta pero sólo tiene efecto después de que se asigne una dirección IP válida. Durante este tiempo, si las llamadas MGCP están activas, se rechaza el comando mgcp bind.
Cuando la interfaz enlazada deja de funcionar, ya sea debido a un apagado manual en la interfaz o debido a una falla de funcionamiento, la actividad de enlace se inhabilita en esa interfaz.
Cuando el enlace no está configurado en el controlador de gateway de medios (MGC), la dirección IP que se utiliza para controlar el MGCP de origen y los medios es la mejor dirección IP disponible.
Si tiene un gateway de Cisco IOS que se conecta a una compañía telefónica o un switch, verifique que la supervisión de respuesta se envíe correctamente cuando el dispositivo llamado detrás de la compañía telefónica o el switch conteste la llamada. Si no se recibe la supervisión de respuesta, el gateway del IOS de Cisco no puede cortar (abrir) la trayectoria de audio en una dirección de reenvío. Este fallo provoca una voz unidireccional. Una solución alternativa es ejecutar el comando voice rtp send-recv on.
Para obtener más información, vea Cut Through Two-Way Audio Early with the voice rtp send-recv Command en Cisco IOS Gateway and Routers.
La trayectoria de voz se establece en la dirección hacia atrás al inicio del flujo RTP. La trayectoria de audio de reenvío no se corta hasta que el gateway de Cisco IOS recibe un mensaje de conexión del extremo remoto.
En algunos casos, es necesario establecer un trayecto de audio bidireccional tan pronto como se abre el canal RTP, que es antes de que se reciba el mensaje Connect. Para lograr esto, ejecute el comando de configuración global voice rtp send-recv.
Este problema se aplica a escenarios, como el desvío de llamadas, en los que más de un router o gateway de Cisco IOS está involucrado en la ruta de voz y se utiliza RTP comprimido (cRTP). cRTP, o compresión de encabezado RTP, es un método para reducir los encabezados de paquetes VoIP a fin de recuperar el ancho de banda. cRTP toma la IP de 40 bytes, el Protocolo de datagramas de usuario (UDP) o el encabezado RTP en un paquete VoIP y lo comprime a 2 o 4 bytes por paquete. Esta compresión produce aproximadamente 12 kbps de ancho de banda para una llamada codificada G.729 con cRTP. Para obtener más información sobre cRTP, consulte Voz sobre IP - Consumo de ancho de banda por llamada.
cRTP se realiza salto por salto, con descompresión y recompresión en cada salto. Cada encabezado de paquete debe ser examinado para el ruteo. Por lo tanto, cRTP debe habilitarse en ambos lados de un link IP.
También es importante verificar que cRTP funciona como se espera en ambos extremos del link. Los niveles de versión del software Cisco IOS varían en términos de trayectos de switching y soporte cRTP simultáneo.
Esto se resume a lo siguiente:
En las versiones del software del IOS de Cisco anteriores a la versión 12.0(5)T del software del IOS de Cisco, cRTP es conmutado por proceso.
En Cisco IOS Software Release 12.0(7)T, y en Cisco IOS Software Release 12.1(1)T, se introduce el soporte de conmutación fast- y Cisco Express Forwarding (CEF) para cRTP.
En Cisco IOS Software Release 12.1(2)T, se introducen mejoras de rendimiento algorítmicas.
Si ejecuta cRTP en las plataformas de software de Cisco IOS (Cisco IOS Software Release 12.1), verifique que el ID de bug de Cisco CSCds08210 no afecte su versión de software de Cisco IOS. El síntoma de este error es la falla de VoIP y fax sobre IP para trabajar con la compresión del encabezado RTP activada.
Solo los usuarios registrados de Cisco pueden acceder a la información y las herramientas de errores internas de Cisco.
Si encuentra que hay errores de reloj en la interfaz E1 o T1 del comando show controller {e1 | t1}, puede haber alguna discordancia en la configuración de temporización de la puerta de enlace de voz. Consulte Configuraciones de Temporización en Plataformas Basadas en Cisco IOS con Capacidad de Voz y asegúrese de que las configuraciones de temporización en la Gateway de Voz sean correctas.
Si utiliza la traducción de direcciones de red (NAT), debe cumplir los requisitos mínimos de nivel de software. Las versiones anteriores de NAT no admiten la traducción de protocolos skinny. Estas versiones anteriores dan lugar a problemas de voz unidireccionales.
Debe ejecutar Cisco IOS Software Release 12.1(5)T o posterior para que los gateways de Cisco IOS admitan skinny y H.323 versión 2 con NAT simultáneamente. Para obtener más información, refiérase a Soporte NAT de Teléfono IP a Cisco CallManager.
Nota: Si Cisco CallManager utiliza un puerto TCP para señalización superficial que es diferente del puerto predeterminado (2000), debe ajustar el router NAT. Ejecute el comando de configuración global ip nat service skinny tcp port number.
El nivel de software mínimo requerido para utilizar NAT y Skinny simultáneamente en un firewall PIX es 6.0. Para obtener más información, consulte Cisco PIX Firewall Version 6.0.
Nota: estos niveles de software no son necesariamente compatibles con todos los mensajes de Registro, Admisión y Estado (RAS) necesarios para la compatibilidad total con el control de acceso. El soporte del controlador de acceso está fuera del alcance de este documento.
El comando de software Cisco IOS voice-fastpath enable es un comando de configuración global oculto para AS5350 y AS5400. El comando está habilitado de forma predeterminada. Para inhabilitarlo, ejecute el comando de configuración global no voice-fastpath enable.
Cuando el comando está habilitado, almacena en caché la información de dirección IP y número de puerto UDP para el canal lógico que se abre para una llamada específica. El comando evita que la secuencia RTP llegue a la capa de aplicación. En su lugar, los paquetes se reenvían a una capa inferior. Esto ayuda a reducir la utilización de la CPU de forma marginal, en situaciones de gran volumen de llamadas.
Cuando se utilizan servicios suplementarios tales como retención o transferencia, el comando voice-fastpath hace que el router transmita el audio a la dirección IP en caché y al puerto UDP. La nueva información de canal lógico que se genera después de que se reanude una llamada en espera o después de que se complete una transferencia no se tiene en cuenta. Para evitar este problema, el tráfico debe ir a la capa de aplicación constantemente para que se tenga en cuenta la redefinición del canal lógico y el audio se transmita a la nueva dirección IP y al par de puertos UDP. Por lo tanto, asegúrese de inhabilitar voice-fastpath para soportar los servicios suplementarios.
Cisco IP SoftPhone permite que un PC funcione como un teléfono Cisco IP Phone 7900 Series. Los usuarios remotos que vuelven a conectarse a la red de su empresa a través de una red privada virtual (VPN) deben configurar algunos parámetros adicionales para evitar un problema de voz unidireccional. Esto se debe a que la secuencia de medios debe conocer el extremo de la conexión.
La solución consiste en configurar la dirección IP de VPN, en lugar de la dirección IP del adaptador de red, en Network Audio Settings (Parámetros de audio de red). Para obtener más información, consulte Cómo Utilizar Cisco IP SoftPhone sobre VPN.
Un Cisco VPN 3002 Hardware Client puede funcionar en dos modos: modo cliente y modo de extensión de red (NEM). En el modo cliente, todos los hosts detrás del cliente Cisco VPN 3002 son direcciones de puerto traducidas a la dirección IP externa del cliente VPN 3002. H.323 no funciona con la traducción de direcciones de puerto (PAT) y da como resultado audio unidireccional cuando un teléfono IP se coloca detrás de un cliente VPN 3002. Cuando VPN 3002 funciona en NEM, las redes remotas pueden verse entre sí a través de sus direcciones IP reales, no a través de una dirección IP basada en NAT o PAT. Si el VPN 3002 está configurado para funcionar en NEM, H.323 puede funcionar. En otras palabras, los teléfonos IP que están detrás de un cliente VPN 3002 sólo pueden funcionar cuando VPN 3002 funciona en NEM. Por lo tanto, para evitar problemas de voz unidireccional con un cliente VPN 3002, configure el cliente VPN 3002 para utilizar NEM.
Para configurar el Cisco VPN 3002 Hardware Client para utilizar NEM, elija Configuration > Quick > PAT y haga clic en No, use Network Extension mode en la ventana PAT.
Para obtener más información, consulte Configuración del Cliente de Hardware de Cisco VPN 3002 en el Router Cisco IOS con EzVPN en el Modo de Extensión de Red
Dos comandos útiles para verificar el flujo de paquetes son el comando debug cch323 rtp y el comando debug voip rtp. El comando debug cch323 rtp muestra los paquetes transmitidos (X) y recibidos (R) por el router. Un carácter en mayúscula indica una transmisión o recepción correcta. Un carácter en minúsculas indica que se ha descartado un paquete.
voice-ios-gwy#debug cch323 rtp RTP packet tracing is enabled voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# voice-ios-gwy# !--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. Mar 3 23:46:23.690: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXXrrrrrrrrrrrrrrrr voice-ios-gwy# voice-ios-gwy# !--- This is an example of an answered call: voice-ios-gwy# voice-ios-gwy# *Mar 3 23:53:26.570: ****** cut through in FORWARD direction ***** XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr !--- At this point, the remote end picks up the phone. *Mar 3 23:53:30.378: ****** cut through in BOTH direction ***** XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR !--- This is the end of the conversation.
Nota: En Cisco IOS Software Release 12.2(11)T y posteriores, el comando debug cch323 rtp command-line interface (CLI) ha sido reemplazado por el comando debug voip rtp.
voice-ios-gwy#debug voip rtp --------cut through in BOTH direction------------------- *Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002), pt=0, ts=4FFBF0, ssrc=8E5FC294 *Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C8D9, ssrc=1F1E5093 *Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002), pt=0, ts=4FFC90, ssrc=8E5FC294 *Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002), pt=0, ts=5D00C979, ssrc=1F1E5093 *Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002), pt=0, ts=4FFD30, ssrc=8E5FC294 *Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CA19, ssrc=1F1E5093 *Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002), pt=0, ts=4FFDD0, ssrc=8E5FC294 *Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CAB9, ssrc=1F1E5093 *Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002), pt=0, ts=4FFE70, ssrc=8E5FC294 *Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CB59, ssrc=1F1E5093 *Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002), pt=0, ts=4FFF10, ssrc=8E5FC294 *Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CBF9, ssrc=1F1E5093 *Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002), pt=0, ts=4FFFB0, ssrc=8E5FC294 *Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002), pt=0, ts=5D00CC99, ssrc=1F1E5093 *Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002), pt=0, ts=500050, ssrc=8E5FC294 *Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DEB9, ssrc=1F1E5093 *Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002), pt=0, ts=501270, ssrc=8E5FC294 *Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DF59, ssrc=1F1E5093 *Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002), pt=0, ts=501310, ssrc=8E5FC294 *Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002), pt=0, ts=5D00DFF9, ssrc=1F1E5093
Puede resolver problemas de llamadas unidireccionales recopilando información de tráfico de llamadas a través del Firewall PIX. El comando capture de PIX se puede utilizar para verificar que el puerto está abierto y se utiliza cuando se produce una llamada. Consulte Manejo del Tráfico VoIP con el Firewall PIX para obtener más información sobre el tráfico VoIP a través del Firewall PIX.
Nota: Asegúrese de inhabilitar el comando capture después de generar los archivos de captura que necesita para resolver problemas.
Este problema solo puede ocurrir en una configuración de llamada SIP inicial saliente donde se requiere MTP. En este caso, el mensaje SIP INVITE saliente puede contener una oferta SDP. El problema puede ocurrir en estos escenarios:
Llamadas troncales SIP salientes con punto de terminación de medios necesario marcado en el troncal SIP
Llamadas entre terminales solo IPv6 y terminales solo IPv4
Los recursos MTP se pueden filtrar de forma intermitente, lo que provoca un error en las llamadas SIP que requieren recursos MTP. Desde RTMT, los recursos MTP disponibles alcanzan 0 y los recuentos de fallas de asignación MTP aumentan para cada llamada que requiere un MTP. La parte SDP de la INVITE inicial puede contener incorrectamente a=inactive.
Complete estos pasos para resolver el problema:
Desmarque Media Termination Point Required en la configuración del troncal SIP, si es posible.
Si se requiere la oferta anticipada, configure la oferta anticipada, pero deje sin marcar Punto de terminación de medios obligatorio.
Para la implementación de IPv6, utilice una pila doble en lugar de terminales solo de IPv6.
Nota: Esto se documenta en la identificación de error de Cisco CSCtk77040. Solo los usuarios registrados de Cisco pueden acceder a la información y las herramientas de errores internas de Cisco.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
11-Oct-2001 |
Versión inicial |