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 los fundamentos de varios protocolos VoIP para ayudar a los ingenieros en la resolución de problemas de manera eficaz en firewalls seguros.
No hay requisitos específicos para este documento.
Este documento está pensado para su uso en situaciones de solución de problemas con estos dispositivos:
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.
La comunicación es fundamental para las interacciones humanas. Los protocolos de voz sobre IP (VoIP) se han vuelto indispensables para la comunicación humana. Por ello, es importante conocer sus partes a la hora de solucionar problemas en un escenario que incluya un firewall (FW).
El VoIP se compone de dos partes:
Las comunicaciones VoIP siempre comienzan con una parte de señalización para iniciar una llamada, a continuación, se transmiten los medios (voz o vídeo) y, finalmente, la señalización finaliza la llamada.
Nota: SIP es el protocolo más utilizado, por lo que se representa de forma coherente como el icono del servidor de voz SIP en muchos de los diagramas.
Consejo: Al solucionar un problema de voz para ASA o FTD, es crucial considerar el escenario desde la perspectiva del usuario. Debe determinar si la llamada se ha establecido o si no hay audio o audio unidireccional. Esta información proporciona pistas valiosas sobre si el problema reside en el protocolo de señalización o en el protocolo de medios (voz o vídeo).
Consejo: Un dispositivo de voz puede gestionar el tráfico del protocolo de transporte en tiempo real (RTP) de voz, el tráfico de señalización o ambos simultáneamente. Al solucionar problemas de voz, es esencial recordar estos conceptos principales:
++Servidores de señalización: Estos servidores son responsables de manejar solamente el tráfico de señalización.
++Servidores de medios: Estos servidores manejan tráfico RTP de voz exclusivamente.
++Algunos dispositivos pueden encargarse de ambas tareas.
El protocolo de señalización es la parte de una llamada que inicia la comunicación de voz, pero no solo eso, sino que también realiza estas funciones:
Los diferentes tipos de protocolos de señalización ayudan a establecer una llamada, y los más comunes incluyen:
Consejo: Es esencial identificar el protocolo de señalización en uso para determinar los puertos apropiados para la captura de paquetes en ASA o FTD. Además, tener una topología de red y un flujo de llamadas es beneficioso para comprender la ruta de señalización.
Nota: Los paquetes de señalización incluyen direcciones IP de origen y destino, que ayudan en la identificación de las partes involucradas en el envío y la recepción del flujo de medios RTP.
Una vez que se ha completado la señalización y los componentes de señalización (dispositivos o servidores) coinciden en el tipo de medio, entra en juego el protocolo en tiempo real (RTP) para comenzar a enviar medios (audio o vídeo) a todas las partes involucradas.
RTP es un protocolo de Internet que se utiliza para la transmisión multimedia que se envía solo después de establecer la llamada y que se ejecuta a través del protocolo de datagramas de usuario (UDP).
Nota: Los medios pueden ser voz y/o video y viajan en paquetes RTP.
Los componentes de señalización (dispositivos o servidores) determinan qué puertos se utilizan para enviar o recibir medios (audio o vídeo). El intervalo de puertos más común para RTP suele estar entre 16384 y 32767 para la mayoría de los dispositivos.
Nota: Ciertos dispositivos de Cisco, como las plataformas ASR e ISR G3, como la plataforma ISR4K, utilizan un intervalo de puertos RTP estandarizado de 8000 a 48200. Es fundamental verificar el intervalo de puertos RTP específico configurado en sus dispositivos, ya que puede diferir de estos valores estandarizados y puede variar entre dispositivos de terceros.
Consejo: A veces, la trayectoria RTP difiere de la trayectoria de señalización, por lo que es crucial identificar los dispositivos responsables del envío y la recepción de paquetes RTP de voz. Esto garantiza que se capture el tráfico UDP entre los dispositivos que atraviesan el ASA o FTD.
Hay dos flujos de medios o flujos RTP que se generan en una llamada de voz normal:
Nota: A modo de ejemplo, el icono del servidor SIP se utiliza para representar un servidor de señalización o un servidor de medios en todas las imágenes.
Al hablar de la transmisión de medios en una llamada de voz, es importante destacar dos situaciones clave:
El flujo de medios es un modo en el que el mismo dispositivo procesa los paquetes de medios (voz y/o vídeo) y de señalización.
El flujo de flujo de medios es un modo en el que los paquetes de señalización se gestionan mediante dos componentes de señalización independientes (dispositivos o servidores), mientras que el flujo de medios (voz o vídeo) se gestiona mediante un tercer dispositivo conocido como dispositivo de medios.
Este modo aclara las funciones de los dispositivos implicados y la distinción entre la señalización y las transmisiones de medios o dispositivos.
Nota: Esto es especialmente importante mencionar cuando la resolución de problemas de la lista de acceso creada podría permitir los componentes de señalización (dispositivos o servidores), pero si el flujo de medios está utilizando otro dispositivo de medios, tenemos que permitirlo también en la lista de acceso de nuestro dispositivo FW.
SIP es un protocolo de control de la capa de aplicación definido por el Grupo de trabajo de ingeniería de Internet (IETF) en RFC 3261.
SIP es un protocolo basado en texto. Esto significa que los mensajes SIP están compuestos de texto legible por personas, de manera similar a como funciona HTTP.
SIP está diseñado para abordar las funciones de señalización y administración de sesiones dentro de una red de telefonía por paquetes.
SIP puede:
SIP se puede utilizar UDP o TCP en el puerto estandarizado 5060. Además, si el SIP se cifra mediante la seguridad de la capa de transporte (TLS), puede utilizar el puerto estandarizado 5061.
Nota: Cuando la señalización SIP está cifrada, los paquetes SIP reales no son visibles en las capturas de paquetes en dispositivos ASA o FTD. Sin embargo, aún puede observar el protocolo de enlace TCP seguido del protocolo de enlace TLS entre los clientes SIP y los dispositivos de servidor SIP.
Nota: La inspección de SIP está activada de forma predeterminada en Cisco Secure Firewall Threat Defense (FTD) y Secure Firewall Adaptive Security Appliance (ASA).
Precaución: Corroborar siempre qué puertos se utilizan para la señalización. Recuerde que el protocolo SIP suele utilizar los puertos 5060 o 5061, pero algunas implementaciones pueden desviarse de estos estándares y utilizar diferentes puertos para el protocolo SIP.
Hay tres situaciones que se pueden encontrar al resolver un problema de señalización SIP:
Los mensajes SIP principales para establecer y finalizar una llamada de voz son los siguientes:
Los mensajes de OPCIONES SIP son importantes para determinar si un dispositivo SIP está en línea y puede responder. Es como un mensaje de ping ICMP pero en el mundo SIP.
Otro mensaje SIP que puede encontrar durante una sesión de solución de problemas del firewall es el mensaje SIP REGISTER, que permite que un dispositivo se registre en un servidor SIP.
Esta captura de paquetes muestra las solicitudes y respuestas de dos dispositivos SIP y también el tráfico de medios (voz):
Este es un ejemplo de un flujo de señalización SIP y medios RTP (voz):
El protocolo de descripción de sesión (SDP) es una representación estándar que se utiliza para describir transmisiones de medios para sesiones multimedia. No transporta medios en sí, pero se utiliza para negociar el tipo de medios y el formato entre los terminales. SDP se utiliza junto con el protocolo de inicio de sesión (SIP) para administrar y negociar las características multimedia de una sesión.
Nota: MGCP incorpora el concepto de SDP, que se utiliza para el mismo propósito.
Este es un ejemplo de mensaje SDP dentro de un protocolo SIP:
INVITE sip:2003@192.168.245.9:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.245.6:5060;branch=z9hGXXX5763
Remote-Party-ID: ;party=calling;screen=no;privacy=off
From: ;tag=4E3XXXC-A9F
To:
Date: Thu, 17 Aug 2025 13:48:52 GMT
Call-ID: 2A7BE22B-XXXXXXXXX-XXXXXXXXX-F940DC75@192.168.245.6
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0350227076-XXXXXXXXX-XXXXXXXXX-1670485135
User-Agent: Cisco-SIPGateway/IOS-15.5.3.S4b
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 150299CC32
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp <=======Session Description Protocol message start
Content-Disposition: session;handling=required
Content-Length: 266
v=0
o=CiscoSystemsSIP-GW-UserAgent 7317 4642 IN IP4 192.168.245.6
s=SIP Call
c=IN IP4 192.168.245.6
t=0 0
m=audio 8266 RTP/AVP 18 127
c=IN IP4 192.168.245.6
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=fmtp:127 0-16
a=ptime:20
Nota: Algunos de los mensajes SDP contienen estos parámetros en el ejemplo:
++c-IN IP4: Dirección IP del servidor de medios
++m=audio: Esto indica que el tipo de medio es audio.
826 ++: Este es el número de puerto en el que se enviará la secuencia de audio.
++RTP/AVP: Especifica el protocolo de transporte, que es RTP con el perfil de audio y vídeo (AVP).
18 127 ++: Estos son los tipos de carga útil para los códecs de audio. El tipo de carga útil 18 corresponde normalmente al códec G.729 y 127 es un tipo de carga útil dinámica que se puede asignar a un códec según la negociación entre los extremos.
El protocolo de descripción de sesión (SDP) se puede encontrar dentro de varios mensajes SIP como: INVITACIÓN, 183 sesiones en curso, 200 OK, ACK, etc. SDP sirve como método de respuesta para intercambiar capacidades de voz o vídeo entre las partes. A la hora de solucionar problemas de llamadas, es fundamental comprender tres conceptos principales:
Nota: Es fundamental comprender el destino de los mensajes SDP, ya que la función de inspección del firewall puede modificar las direcciones IP no solo dentro de los encabezados SIP, sino también en la sección SDP.
Aquí, los parámetros de medios en SDP se encuentran dentro de los mensajes SIP INVITE y 200 OK.
En este método, el SDP se encuentra en 200 mensajes SIP OK y ACK.
Los medios tempranos se transmiten a través de un mensaje SIP específico conocido como respuesta de progreso de sesión 183. Este mensaje incluye el protocolo de descripción de sesión (SDP) que contiene los parámetros de medios para la parte llamada. Los operadores y los proveedores de SIP lo utilizan habitualmente para enviar mensajes de voz automatizados u otros medios a la persona que llama antes de que la llamada se conecte oficialmente.
H.323 es un conjunto de protocolos definidos por la Unión Internacional de Telecomunicaciones (ITU) para las comunicaciones de voz, vídeo y datos a través de redes conmutadas por paquetes, como Internet.
El protocolo H.323 se compone de dos componentes principales:
Los puertos utilizados por el protocolo de señalización H.323 son 1718, 1719 y 1720.
Consejo: Las comunicaciones de protocolo H.323 seguras pueden encontrar problemas al cambiar de UDP a TCP debido al uso de TLS para cifrado, lo que puede hacer que un firewall bloquee erróneamente la conexión como actividad sospechosa, por lo que es crucial configurar el firewall para permitir el tráfico UDP y TCP para los terminales o servidores H.323.
H.323 es un protocolo que tiene dos modos de operación: arranque lento y arranque rápido.
Este protocolo es responsable de configurar la llamada y finalizar una llamada de voz cuando una de las partes cuelga.
H.245 proporciona estas funcionalidades:
Nota: Los términos Master y Slave utilizados en este documento están codificados en el protocolo H.323 original y no reflejan las políticas o valores de nuestra empresa. Estamos comprometidos con la promoción de un lenguaje inclusivo y respetuoso.
El protocolo H.245 se envía después de recibir el mensaje de conexión H.225.
Este protocolo ayuda a determinar qué protocolo de voz se utiliza para RTP y se especifica en los mensajes de canal lógico de apertura y cierre para él.
Esta captura de paquetes muestra las solicitudes y respuestas de dos dispositivos H.323 con H.225 y H.245 y también el tráfico de medios (voz):
Este es un ejemplo de un flujo de señalización H.323 con medios H.225 y H.245 y RTP (voz):
Nota: La inspección H.323 está activada de forma predeterminada en Cisco Secure Firewall Threat Defense (FTD) y Secure Firewall Adaptive Security Appliance (ASA).
En el modo de inicio lento, el proceso de configuración de la llamada implica varios pasos de señalización antes de que se establezcan los canales de medios. Entre los pasos se incluyen Setup (Configuración), Call Proceeding (Procedimiento de llamada), Alerting (Alerta) y Connect (Conectar). Después de estos pasos, la negociación de medios H.245 se realiza por separado. Esto significa que los canales de medios no se establecen hasta después de que se haya completado la señalización de llamada inicial, lo que puede resultar en un tiempo de configuración más largo.
Por el contrario, el modo de inicio rápido permite que se produzca la negociación de medios dentro del mensaje de configuración inicial. Esto significa que los canales de medios se pueden establecer más rápidamente, ya que la negociación se realiza como parte de la configuración de llamada inicial. Fast Start simplifica el proceso al reducir el número de mensajes intercambiados y la cantidad de procesamiento necesario antes de establecer los canales de medios.
El protocolo de control de clientes (SCCP) Skinny, a menudo denominado simplemente Skinny, es un protocolo de señalización propiedad de Cisco. Los utilizan principalmente Cisco Unified Communications Manager (CUCM), los routers Cisco Unified Communications Manager Express (CME) y los Cisco IP Phones para facilitar la configuración y el control de las llamadas.
El protocolo SCCP utiliza TCP en el puerto 2000 para SCCP no seguro y utiliza el puerto 2443 para SCCP seguro.
Estos son los mensajes SCCP comunes que puede encontrar en una llamada SCCP:
Esta captura de paquetes muestra las solicitudes y respuestas de dos dispositivos SCCP y también el tráfico de medios (voz):
Este es un ejemplo de un flujo de señalización SCCP y medios RTP (voz):
Nota: La inspección SCCP está activada de forma predeterminada en Cisco Secure Firewall Threat Defense (FTD) y Secure Firewall Adaptive Security Appliance (ASA).
El protocolo de control de gateway de medios (MGCP) es un protocolo utilizado para el control de llamadas VoIP por un dispositivo de control de llamadas, por ejemplo, CUCM.
El protocolo de señalización MGCP se define en RFC 2705 y utiliza el puerto TCP 2428 y el puerto UDP 2427 para la comunicación.
Los paquetes normales MGCP que se esperan para una comunicación de llamada son:
Nota: La inspección MGCP no está habilitada en la política de inspección predeterminada en Cisco Secure Firewall Threat Defense (FTD) y Secure Firewall Adaptive Security Appliance (ASA), por lo que debe habilitarla si necesita esta inspección.
Esta captura de paquetes muestra las solicitudes y respuestas de dos dispositivos MGCP y también el tráfico de medios (voz):
Este es un ejemplo de un flujo de señalización MGCP y medios RTP (voz):
Para ASA:
Nota: Recuerde que estos dispositivos de audio o medios podrían ser diferentes de los componentes de señalización (dispositivos o servidores).
Para FTD:
Al solucionar problemas de voz, debe saber si el problema es de señalización o multimedia (voz o vídeo) o ambos. A continuación, se incluyen algunos ejemplos que pueden guiarle para diferenciarlo:
Ejemplo de problemas de señalización:
++El usuario informa de que no se ha establecido la llamada.
++El usuario no puede llamar a otros usuarios o números.
++El troncal SIP no aparece, porque el mensaje SIP OPTIONS no recibe respuesta.
++Mi dispositivo no se puede registrar.
Ejemplo de problemas de medios (voz o vídeo):
++Hay un problema de audio unidireccional.
++No hay audio en la llamada.
++No hay vídeo en absoluto.
++La llamada se silencia.
Consejo: Durante una videollamada, el SDP puede negociar hasta tres líneas de medios (líneas m): audio, vídeo e imagen. Cada línea m corresponde a una secuencia independiente de protocolo de transporte en tiempo real (RTP) por segmento de llamada, lo que significa que puede haber hasta tres transmisiones RTP distintas (una para cada tipo de medio) en cada segmento de la llamada.
Para la resolución de problemas de la parte de señalización debe asegurarse de:
++Identifique todos los componentes de señalización (dispositivos o servidores) involucrados en la llamada desde la interfaz de ingreso y egreso y configure los criterios de coincidencia apropiados en las capturas de paquetes en CLI de cualquiera de los FW seguros.
++Recuerde que el número de mensajes de señalización en la interfaz de ingreso debe coincidir con la interfaz de egreso.
++La captura de paquetes se puede hacer más eficiente especificando si el protocolo de señalización utiliza TCP o UDP y filtrando el número de puerto esperado. Dado que todos los protocolos de señalización funcionan sobre IP, la aplicación de estos filtros en la CLI ayuda a restringir la cantidad de tráfico que ve en las capturas.
++Sólo para interfaces de salida, asegúrese de que la dirección IP de NAT asignada al tráfico saliente se especifica en el filtro de captura de paquetes. Esto garantiza que está capturando el tráfico correcto tal como aparece en la interfaz de salida.
Nota: Recuerde que, independientemente del protocolo de señalización que se utilice para la voz, siempre debe haber una solicitud y una respuesta, y debe ser consistente tanto en las interfaces de ingreso como de egreso.
Nota: siempre que sea posible, asegúrese de que solo haya un firewall involucrado en la ruta de comunicación. En algunas implementaciones, la señalización de voz y las transmisiones multimedia pueden atravesar firewalls independientes. En estos casos, asegúrese de incluir todos los firewalls relevantes en el proceso de solución de problemas
Desde la perspectiva de FW, habrá 4 flujos que se deben analizar al resolver problemas de audio unidireccional, problemas de audio bidireccional o sin audio:
Flujo RTP de la persona que llama a la persona que llama (interfaz de entrada).
Flujo RTP de la persona que llama a la persona que llama (interfaz de salida).
Flujo RTP de la persona que llama a la que llama (interfaz de salida).
Flujo RTP de la persona que llama a la que llama (interfaz de entrada).
Nota: Asegúrese de realizar la resolución de problemas mediante capturas de paquetes CLI en el modo ASA o LINA en el FTD, ya que esto proporciona una mayor flexibilidad para aplicar varias coincidencias dentro de una sola captura de paquetes.
Al solucionar problemas de voz en Secure FW (ASA o FTD), debe llevar a cabo estos pasos:
Consejo: Los mensajes de señalización SIP que ingresan al FW también deben ser los mismos que los que salen del FW.
Nota: Las sugerencias de solución de problemas para SIP también se pueden aplicar a los protocolos H.323, MGCP y SCCP.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
06-Aug-2025
|
Versión inicial |