Este documento aborda algunos de los problemas comunes que pueden ocurrir en las conversaciones de audio unidireccional a través de telefonía IP relacionados con gateways Cisco. Las gateways de Cisco que abarca este documento son las gateways y routers Cisco IOS®, los switches Catalyst y las gateways DT-24+.
Este documento está dirigido al personal que participa en las redes de telefonía IP y tiene conocimientos básicos de las redes de voz.
Este documento no se limita a una versión específica de software o de hardware.
Este documento proporciona escenarios y soluciones a estos problemas:
Cuando se establece una llamada telefónica desde una estación IP a través de un router o gateway de voz del IOS de Cisco, sólo una de las partes recibe audio (comunicación unidireccional).
Cuando se establece una llamada de desvío de llamadas entre dos gateways de Cisco, sólo una de las partes recibe audio (comunicación unidireccional).
Cuando se establece una llamada telefónica desde una estación IP ubicada detrás de un cliente de hardware VPN 3002, sólo una de las partes recibe audio (comunicación unidireccional).
Las causas del audio unidireccional en la telefonía IP pueden ser diversas, pero la raíz del problema generalmente implica problemas de ruteo IP. En esta sección se analizan algunos de los escenarios y soluciones que se han encontrado en este campo.
Algunos gateways de Cisco IOS, como el VG200, desactivan el ruteo IP de forma predeterminada. Esta configuración predeterminada provoca problemas de voz unidireccionales.
Nota: Antes de continuar, asegúrese de que el routing 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
Siempre verifique primero el alcance IP básico. Debido a que las secuencias de protocolo de transporte en tiempo real (RTP) no tienen conexión (se transportan a través de UDP), el tráfico puede viajar con éxito 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 establecida 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 solución de problemas de IP Routing para llegar a la etapa en la que puede hacer ping con éxito 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 IP Routing. Sin embargo, confirme que estos son algunos de los pasos iniciales que se deben seguir:
Los gateways predeterminados se configuran en las estaciones finales.
Las rutas IP en esos gateways predeterminados llevan a las redes de destino.
Nota: Esta lista explica cómo verificar la configuración predeterminada del router o la gateway en varios teléfonos IP de Cisco:
Teléfono IP Cisco 7910: presione Settings, seleccione la opción 6 y presione el volumen hacia abajo hasta que aparezca el campo Default Router (Router predeterminado).
Teléfono IP Cisco 7960/40: presione Settings, seleccione la opción 3 y desplácese hacia abajo hasta que aparezca el campo Default Router (Router predeterminado).
Teléfono IP de Cisco 2sp+/30vip: presione **# y, a continuación, presione # hasta que aparezca gtwy=.
Nota: Cuando utiliza la aplicación Cisco IP SoftPhone y se instala más de una tarjeta de interfaz de red (NIC) en la caja, asegúrese de que la caja obtenga la NIC correcta. Este problema suele estar presente en la versión 1.1.x del software IP SoftPhone. La versión 1.2 debe resolver este problema.
Nota: Cuando utilice Cisco DT-24+ Gateways, 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 en los dispositivos y PC. La opción de alcance 3 debe tener la dirección IP de la interfaz del router que ruteará para el gateway.
Si la transcodificación está configurada para un troncal entre clústeres (ICT), asegúrese de que un punto de terminación de medios (MTP) esté configurado en el grupo de recursos de medios y en la lista de grupos de recursos de medios asociada al tronco. Si especifica un MTP cuando no se necesita o no configura un MTP si es necesario, se sabe que causa problemas de voz unidireccionales para las configuraciones de ICT.
Cuando el gateway del IOS de Cisco tiene varias interfaces IP activas, algunas de las señalizaciones H.323 se pueden originar en una dirección IP y otras partes del mismo 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 solucionar este problema, puede enlazar 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 (loopback). Utilice el comando h323-gateway voip bind srcaddr ip-address en el modo de configuración de la interfaz. Configure este comando bajo la interfaz con la dirección IP a la que apunta Cisco CallManager.
Este comando se introdujo en la versión 12.1(2)T del software del IOS de Cisco. Consulte Soporte H.323 para Interfaces Virtuales.
Precaución: Existe un bug en Cisco IOS Software Release 12.2(6) en el cual esta solución puede en realidad causar un problema de audio unidireccional. Para obtener más información, consulte el Id. de bug Cisco CSCdw69681 (sólo clientes registrados) .
La voz unidireccional puede ocurrir en las puertas de enlace del protocolo de control de gateway de medios (MGCP) si no se especifica la interfaz de origen para la señalización y los paquetes de medios. Puede enlazar el medio MGCP a la interfaz de origen si ejecuta el comando mgcp bind media source-interface interface-id y luego el comando mgcp bind control source-interface interface-id . Reinicie el gateway MGCP en Cisco CallManager después de ejecutar los comandos.
Si el comando mgcp bind no está habilitado, la capa IP todavía proporciona la mejor dirección local.
Las pautas para el comando mgcp bind son:
Cuando hay llamadas MGCP activas en el gateway, el comando mgcp bind se rechaza tanto para el control como para los medios.
Si la interfaz de enlace no está activa, se acepta el comando pero no surte efecto hasta que se active la interfaz.
Si la dirección IP no se asigna en la interfaz de enlace, el comando mgcp bind se acepta pero sólo se aplica después de que se asigne una dirección IP válida. Durante este tiempo, si las llamadas MGCP están activas, el comando mgcp bind se rechaza.
Cuando la interfaz enlazada se desactiva, ya sea por un apagado manual en la interfaz o por una falla operativa, la actividad de enlace se inhabilita en esa interfaz.
Cuando el enlace no está configurado en el Media Gateway Controller (MGC), la dirección IP que se utiliza para el control MGCP de origen y los medios es la mejor dirección IP disponible.
Si tiene una 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 al que se llama detrás de la compañía telefónica o el switch responda 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. Esta falla causa una voz unidireccional. Una solución temporal es ejecutar el comando voice rtp send-recv on.
Para obtener más información, vea Cortar a través de audio bidireccional temprano con el comando voice rtp send-recv en la gateway y los routers de Cisco IOS.
La trayectoria de voz se establece en la dirección descendente al inicio de la secuencia RTP. La trayectoria de audio de reenvío no se corta hasta que la gateway de Cisco IOS recibe un mensaje Connect del extremo remoto.
En algunos casos, es necesario establecer una trayectoria de audio bidireccional tan pronto como se abra 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 la derivación de llamadas, en los que se utiliza más de un router o gateway Cisco IOS en la ruta de voz y RTP comprimido (cRTP). cRTP, o Compresión de Encabezado RTP, es un método para reducir los encabezados de paquetes VoIP para 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 a 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 a salto, con descompresión y recompresión en cada salto. Se debe examinar cada encabezado de paquete para el ruteo. Por lo tanto, cRTP debe estar habilitado en ambos lados de un link IP.
También es importante verificar que cRTP funciona como se esperaba en ambos extremos del link. Los niveles de versión del software Cisco IOS varían en términos de trayectos de conmutación y soporte cRTP simultáneo.
Esto se resume a lo siguiente:
En las versiones del software Cisco IOS anteriores a la versión 12.0(5)T del software Cisco IOS, cRTP se conmuta 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 switching de fast y Cisco Express Forwarding (CEF) para cRTP.
En Cisco IOS Software Release 12.1(2)T, se introducen mejoras algorítmicas en el rendimiento.
Si ejecuta cRTP en las plataformas de software del IOS de Cisco (versión 12.1 del software del IOS de Cisco), verifique que el Id. de error de Cisco CSCds08210 (sólo clientes registrados) no afecte a su versión de software del IOS de Cisco. El síntoma de este bug es la falla de VoIP y fax sobre IP para funcionar con la compresión de encabezado RTP activada.
Si encuentra que hay errores de reloj en la interfaz E1 o T1 desde el show controller {e1 | t1}, puede haber alguna discordancia en la configuración de temporización en la puerta de enlace de voz. Refiérase a Configuraciones de Temporización en Plataformas Basadas en IOS Capaces de Voz y asegúrese de que las configuraciones de temporización en el 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 generan problemas de voz unidireccionales.
Debe ejecutar Cisco IOS Software Release 12.1(5)T o posterior para que los gateways Cisco IOS soporten skinny y H.323 versión 2 con NAT simultáneamente. Para obtener más información, refiérase a Soporte NAT del Teléfono IP a Cisco CallManager.
Nota: Si su Cisco CallManager utiliza un puerto TCP para señalización delgada 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 mínimo de software que se requiere para utilizar NAT y Skinny simultáneamente en un firewall PIX es 6.0. Para obtener más información, consulte Cisco PIX Firewall versión 6.0.
Nota: Estos niveles de software no son necesariamente compatibles con todos los mensajes de Registro, Admisión y Estado (RAS) que son necesarios para el soporte completo del gatekeeper. El soporte del controlador de acceso está fuera del alcance de este documento.
El comando Cisco IOS Software 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 se habilita el comando, almacena en memoria caché la dirección IP y la información del 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 en una capa inferior. Esto ayuda a reducir la utilización de la CPU marginalmente, en situaciones de gran volumen de llamadas.
Cuando se utilizan servicios complementarios como retención o transferencia, el comando voice-fastpath hace que el router transmita el audio a la dirección IP almacenada en caché y al puerto UDP. Se ignora la nueva información del canal lógico que se genera después de que se reanuda una llamada en espera o después de que se complete una transferencia. Para solucionar 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 servicios suplementarios.
Cisco IP SoftPhone permite que un PC funcione como un teléfono IP de Cisco serie 7900. Los usuarios remotos que se conectan 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 punto final de la conexión.
La solución es configurar la dirección IP de VPN, en lugar de la dirección IP del adaptador de red, en Configuración de audio de red. Para obtener más información, refiérase a 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 el VPN 3002 funciona en NEM, las redes remotas pueden verse a través de sus direcciones IP reales, no una dirección IP basada en NAT o basada en PAT. Si la VPN 3002 está configurada 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 unidireccionales con un cliente VPN 3002, configure el cliente VPN 3002 para que utilice NEM.
Para configurar 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 VPN 3002 de Cisco al Router Cisco IOS con EzVPN en el Modo de Extensión de Red
Dos comandos útiles que se deben utilizar 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 que la transmisión o recepción se ha realizado correctamente. Un carácter en minúsculas indica un paquete descartado.
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) se ha 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 de un solo sentido recopilando información de tráfico de llamadas a través del firewall PIX. El comando PIX capture se puede utilizar para verificar el puerto abierto y utilizado cuando ocurre 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 sólo puede ocurrir en una configuración de llamada SIP inicial saliente donde se requiere MTP. En este caso, el mensaje SIP INVITE saliente contendrá una oferta SDP. El problema puede ocurrir en estos escenarios:
Llamadas troncales SIP salientes con punto de terminación de medios necesarias activadas en el troncal SIP
Llamadas entre terminales solo IPv6 y terminales solo IPv4
Es posible que los recursos MTP se filtren de forma intermitente, lo que provoca el error de 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 del INVITE inicial contendrá incorrectamente a=inactivo.
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 oferta anticipada, configure la oferta anticipada, pero deje Media Termination Point Required sin marcar.
Para la implementación de IPv6, utilice dos pilas en lugar de terminales solo IPv6.
Nota: Esto se documenta con el ID de bug CSCtk77040 (sólo clientes registrados) .
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
13-Oct-2008 |
Versión inicial |