SIP ALG

Operación SIP ALG

Hay dos tipos de tráfico SIP, la señalización y el flujo de medios. El tráfico de señalización SIP consta de mensajes de solicitud y respuesta entre el cliente y el servidor, y utiliza protocolos de transporte como UDP o TCP. El flujo de medios transporta los datos (datos de audio, por ejemplo) mediante protocolos de transporte.

A partir de Junos OS versión 12.3X48-D25 y Junos OS versión 17.3R1, el SIP ALG admite TCP. La compatibilidad tcp a través del SIP ALG reduce el tráfico al servidor mediante la eliminación de la necesidad de volver a registrar o actualizar el servidor con frecuencia.

De forma predeterminada, Junos OS admite mensajes de señalización SIP en el puerto 5060. Puede configurar el puerto mediante la creación de una política que permita el servicio SIP y el software filtra el tráfico de señalización SIP como cualquier otro tipo de tráfico, permitándolo o negándolo. Sin embargo, la secuencia de medios usa números de puerto asignados dinámicamente que pueden cambiar varias veces durante el curso de una llamada. Sin puertos fijos, es inseguro crear una política estática para controlar el tráfico de medios. En este caso, el dispositivo invoca la ALG de SIP. Los puertos de transporte del dispositivo utilizados para las sesiones de medios no se conocen de antemano; sin embargo, los puertos utilizados para la negociación del SIP son bien conocidos (o predefinidos). El ALG registra el interés en los paquetes de la sesión de control, que puede distinguir fácilmente de los demás paquetes, e inspecciona la negociación para la información de transporte utilizada para la sesión de medios (tanto las direcciones IP como los puertos).

El SIP ALG monitorea las transacciones de SIP y crea y administra de forma dinámica agujeros basados en la información que extrae de estas transacciones. El ALG SIP de Juniper Networks admite todos los métodos y respuestas del SIP. Puede permitir que las transacciones SIP atraviesen el firewall de Juniper Networks mediante la creación de una política estática que permita el servicio SIP. Si la política está configurada para inspeccionar el tráfico DEL SIP (o, más adecuadamente, si la política envía tráfico al SIP ALG para su inspección), las acciones permitidas son permitir el tráfico (en cuyo caso se abren las perforaciones adecuadas) o denegar el tráfico.

El SIP ALG intercepta mensajes SIP que contienen SDP y, mediante un analizador, extrae la información que requiere para crear agujeros de pin. El SIP ALG examina la parte SDP del paquete, y un analizador extrae información como direcciones IP y números de puerto, que el ALG del SIP registra en una tabla de agujeros pin. El SIP ALG utiliza las direcciones IP y los números de puerto registrados en la tabla de perforaciones para abrir agujeros y permitir que las secuencias de medios atraviesen el dispositivo.

Los productos NEC SIP son compatibles condicionalmente.

Descripciones de sesión de SDP

Una descripción de sesión SDP es un formato bien definido para transmitir información suficiente para descubrir y participar en una sesión multimedia. Una sesión se describe mediante una serie de pares de atributo/valor, uno por línea. Los nombres de atributo son caracteres únicos, seguidos de =, y un valor. Los valores opcionales se especifican con =*. Los valores son una cadena ASCII o una secuencia de tipos específicos separados por espacios. Los nombres de atributos solo son únicos dentro de la construcción sintáctica asociada, como solo en la sesión, el tiempo o los medios.

De los muchos campos de la descripción de SDP, dos son particularmente útiles para la ALG del SIP, ya que contienen información de la capa de transporte.

• c= para obtener información de conexión

  Este campo puede aparecer a nivel de sesión o de medios. Aparece en este formato:

  c=tipo de red <><dirección><conexiones>

  Junos OS solo admite "IN" (para Internet) como tipo de red, "IPv4" como tipo de dirección y una dirección IP de unidifusión o un nombre de dominio como dirección IP de destino (conexión). A partir de Junos OS versión 15.1X49-D40 y Junos OS versión 17.3R1, también se admite el tipo de dirección "IPv6".

  Si la dirección IP de destino es una dirección IP de unidifusión, la ALG del SIP crea agujeros con los números de dirección IP y puerto especificados en el campo de descripción de medios m=.

• m= para el anuncio de los medios

  Este campo aparece a nivel de medios y contiene la descripción de los medios. Aparece en este formato:

  lista de m=<media><port><transporte><fmt>

  Actualmente, Junos OS admite "RTP" como protocolo de transporte de capa de aplicación. El número de puerto indica el puerto de destino de la secuencia de medios (el origen lo asigna el UA remoto). La lista de formatos (lista fmt) proporciona información sobre el protocolo de capa de aplicación que utilizan los medios.

  El software abre puertos solo para RTP y el Protocolo de control en tiempo real (RTCP). Cada sesión de RTP tiene una sesión RTCP correspondiente. Por lo tanto, cada vez que una secuencia de medios usa RTP, el SIP ALG debe reservar puertos (crear agujeros) para el tráfico RTCP y RTP. De forma predeterminada, el número de puerto para RTCP es uno mayor que el número de puerto RTP.

Creación de pinhole

Cada agujero de pin (uno para el tráfico RTP y el otro para el tráfico RTCP) comparten la misma dirección IP de destino. La dirección IP proviene del campo c= en la descripción de la sesión de SDP. Dado que el campo c= puede aparecer en el nivel de sesión o en la parte a nivel de medios de la descripción de la sesión de SDP, el analizador determina la dirección IP según las siguientes reglas (de conformidad con las convenciones de SDP):

• En primer lugar, el analizador DE ALG de SIP busca un campo c= que contiene una dirección IP en el nivel de medios. Si hay un campo de este tipo, el analizador extrae esa dirección IP y la ALG del SIP usa esa dirección para crear un agujero para los medios.

• Si no hay ningún campo c= en el nivel de medios, el analizador ALG de SIP extrae la dirección IP del campo c= en el nivel de sesión, y el ALG del SIP usa esa dirección IP para crear un agujero para los medios. Si la descripción de la sesión no contiene un campo c= en ninguno de los niveles, esto indica un error en la pila de protocolos, y el dispositivo deja caer el paquete y registra el evento.

El SIP ALG también abre agujeros para el tráfico de señal. Estas perforaciones de señal son útiles después del tiempo de espera de la sesión de señal anterior, y también son útiles para el tráfico de señal enviado a una dirección de terceros que no coincide con la sesión de señal anterior. Las perforaciones de señal ALG SIP nunca envejecen, a diferencia de los agujeros de pin RTP o RTCP, donde solo se especifican la IP de destino y el puerto de destino.

La SIP ALG abre agujeros de señal para los siguientes encabezados, si es necesario:

• Vía

• CONTACTO

• RUTA

• RUTA DE REGISTRO

El SIP ALG necesita la siguiente información para crear una perforación. Esta información proviene de la descripción de la sesión de SDP o de los encabezados del SIP (como se indica anteriormente).

• Protocolo: UDP o TCP.

• IP de origen: desconocida.

• Puerto de origen: desconocido.

• IP de destino: el analizador extrae la dirección IP de destino del campo c= en el nivel de medios o sesión.

• Puerto de destino: el analizador extrae el número de puerto de destino para RTP del campo m= en el nivel de medios y calcula el número de puerto de destino para RTCP mediante la siguiente fórmula:

  Número de puerto RTP + uno

• Duración: este valor indica la longitud del tiempo (en segundos) durante el cual una perforación está abierta para permitir el paso de un paquete. Un paquete debe pasar por la perforación antes de que expire la vida útil. Cuando expire la vida útil, la ALG sip elimina el agujero de pin.

  Cuando un paquete pasa por la perforación dentro del período de vida útil, inmediatamente después, el SIP ALG elimina la perforación para la dirección desde la que vino el paquete.

  En la Figura 1 se describe una configuración de llamada entre dos clientes SIP y cómo el SIP ALG crea agujeros para permitir tráfico RTC y RTCP. La ilustración asume que el dispositivo tiene una política que permite el SIP, abriendo así el puerto 5060 para mensajes de señalización SIP.

  Figura 1: Configuración de llamadas SIP ALG

• Descripción de la compatibilidad con IPv6 para SIP ALG
• Descripción de la compatibilidad con el campo de la lámpara ocupada de escalabilidad para el ALG SIP basado en UDP
• Descripción de los métodos de solicitud de SIP ALG
• Descripción general de la configuración de SIP ALG
• Descripción de la protección contra ataques SIP ALG DoS
• Descripción de los tipos de mensajes desconocidos de SIP ALG
• Descripción de la duración y los tiempos de espera de las llamadas ALG del SIP

Retener recursos de retención de ALG de SIP (procedimiento de CLI)

Para admitir flujos de llamadas SIP patentados:

Llamadas salientes

Cuando se inicia una llamada SIP con un mensaje de solicitud SIP desde el interno a la red externa, el TDR reemplaza las direcciones IP y los números de puerto en el SDP y enlaza las direcciones IP y los números de puerto al firewall de Juniper Networks. Los campos de encabezado sip Via, Contact, Route y Record-Route, si están presentes, también están enlazados a la dirección IP del firewall. La ALG almacena estas asignaciones para usarlas en retransmisiones y en mensajes de respuesta SIP.

A continuación, el SIP ALG abre agujeros en el firewall para permitir que los medios a través del dispositivo en los puertos asignados dinámicamente negociados según la información en los campos de encabezado vía, contacto y ruta de registro. Las perforaciones también permiten que los paquetes entrantes lleguen a los puertos y direcciones IP de contacto, vía y ruta de registro. Cuando se procesa el tráfico de retorno, el ALG inserta los campos SIP de contacto, vía, ruta y ruta de registro originales en paquetes.

Llamadas entrantes

Las llamadas entrantes se inician desde la red pública a direcciones TDR estáticas públicas o a direcciones IP de interfaz en el dispositivo. Las NAT estáticas están configuradas estáticamente direcciones IP que apuntan a hosts internos; las direcciones IP de interfaz son grabadas dinámicamente por el ALG mientras monitorea los mensajes DE REGISTRO enviados por hosts internos al registrador del SIP. Cuando el dispositivo recibe un paquete SIP entrante, configura una sesión y reenvía la carga del paquete al SIP ALG.

El ALG examina el mensaje de solicitud sip (inicialmente una INVITACIÓN) y, según la información del SDP, abre puertas para los medios salientes. Cuando llega un mensaje de respuesta 200 OK, el SIP ALG realiza TDR en las direcciones IP y los puertos, y abre agujeros en la dirección de salida. (Las puertas abiertas tienen poco tiempo de vida y tienen tiempo de salida si un mensaje de respuesta 200 OK no se recibe rápidamente.)

Cuando llega una respuesta 200 OK, el proxy SIP examina la información de SDP y lee las direcciones IP y los números de puerto para cada sesión de medios. El SIP ALG del dispositivo realiza TDR en las direcciones y números de puerto, abre agujeros para el tráfico saliente y actualiza el tiempo de espera de las puertas en la dirección de entrada.

Cuando el ACK llega para el 200 OK, también pasa a través del SIP ALG. Si el mensaje contiene información de SDP, la ALG del SIP garantiza que las direcciones IP y los números de puerto no se cambien de la INVITACIÓN anterior: si es así, la ALG elimina los agujeros antiguos y crea nuevas perforaciones para permitir que los medios pasen. La ALG también monitorea los campos SIP Vía, Contacto y Ruta de registro y abre nuevas perforaciones si determina que estos campos han cambiado.

Llamadas reenviadas

Una llamada reenviada es cuando, por ejemplo, el usuario A fuera de la red llama al usuario B dentro de la red, y el usuario B reenvía la llamada al usuario C fuera de la red. El SIP ALG procesa la INVITACIÓN del usuario A como una llamada entrante normal. Sin embargo, cuando la ALG examina la llamada reenviada de B a C fuera de la red y observa que se alcanza a B y C mediante la misma interfaz, no abre agujeros en el firewall, ya que los medios fluyen directamente entre el usuario A y el usuario C.

Terminación de llamadas

El mensaje BYE termina una llamada. Cuando el dispositivo recibe un mensaje BYE, traduce los campos de encabezado del mismo modo que para cualquier otro mensaje. Sin embargo, dado que el receptor debe reconocer un mensaje BYE con una AUTORIZACIÓN de 200, los retrasos de ALG retrasan la llamada durante 5 segundos para permitir el tiempo de transmisión del 200 OK.

Volver a invitar mensajes

Volver a invitar mensajes agregar nuevas sesiones de medios a una llamada y eliminar las sesiones de medios existentes. Cuando se agregan nuevas sesiones de medios a una llamada, se abren nuevos agujeros en el firewall y se crean nuevos enlaces de direcciones. El proceso es idéntico a la configuración de llamada original. Cuando se eliminan todas las sesiones de medios o los agujeros de pin de medios de una llamada, la llamada se elimina cuando se recibe un mensaje BYE.

Temporizadores de sesión de llamada

Como medida de precaución, el SIP ALG utiliza valores de tiempo de espera duro para establecer la cantidad máxima de tiempo que puede existir una llamada. Esto garantiza que el dispositivo esté protegido si ocurre uno de los siguientes eventos:

• Los sistemas finales se bloquean durante una llamada y no se recibe un mensaje BYE.

• Los usuarios maliciosos nunca envían un BYE en un intento de atacar un SIP ALG.

• Las implementaciones deficientes del proxy SIP no pueden procesar la ruta de registro y nunca enviar un mensaje BYE.

• Las fallas de red impiden que se reciba un mensaje BYE.

Cancelación de llamadas

Cualquiera de las partes puede cancelar una llamada mediante el envío de un mensaje CANCEL. Tras recibir un mensaje DE CANCELACIÓN, la ALG del SIP cierra los agujeros del firewall (si se han abierto) y libera los enlaces de direcciones. Antes de liberar los recursos, el ALG retrasa la antigüedad del canal de control durante aproximadamente 5 segundos para permitir el paso del 200 OK final. La llamada se termina cuando expira el tiempo de espera de 5 segundos, independientemente de si llega una respuesta de 487 o no de 200.

Bifurcar

La bifurcación permite que un proxy SIP envíe un único mensaje INVITE a varios destinos simultáneamente. Cuando llegan varios mensajes de respuesta 200 OK para la llamada única, el SIP ALG analiza pero actualiza la información de llamada con los primeros 200 mensajes ok que recibe.

Mensajes SIP

El formato de mensaje SIP consta de una sección de encabezado SIP y el cuerpo del SIP. En los mensajes de solicitud, la primera línea de la sección de encabezado es la línea de solicitud, que incluye el tipo de método, el URI de solicitud y la versión de protocolo. En los mensajes de respuesta, la primera línea es la línea de estado, que contiene un código de estado. Los encabezados SIP contienen direcciones IP y números de puerto utilizados para la señalización. El cuerpo del SIP, separado de la sección del encabezado por una línea en blanco, se reserva para la información de descripción de la sesión, que es opcional. Junos OS admite actualmente solo el SDP. El cuerpo del SIP contiene direcciones IP y números de puerto utilizados para transportar los medios.

Encabezados SIP

En el siguiente mensaje de solicitud SIP de ejemplo, NAT reemplaza las direcciones IP en los campos de encabezado para ocultarlas de la red externa.

La forma en que se realiza la traducción de direcciones IP depende del tipo y la dirección del mensaje. Un mensaje puede ser cualquiera de los siguientes:

• Solicitud entrante

• Respuesta saliente

• Solicitud de salida

• Respuesta entrante

La tabla 1 muestra cómo se realiza el TDR en cada uno de estos casos. Tenga en cuenta que para varios de los campos de encabezado, el ALG determina más que solo si los mensajes provienen de dentro o fuera de la red. También debe determinar qué cliente inició la llamada y si el mensaje es una solicitud o respuesta.

Cuerpo del SIP

La información de SDP en el cuerpo del SIP incluye direcciones IP que el ALG usa para crear canales para la secuencia de medios. La traducción de la sección SDP también asigna recursos, es decir, números de puerto para enviar y recibir los medios.

En el siguiente extracto de una sección SDP de ejemplo se muestran los campos que se traducen para la asignación de recursos.

Los mensajes SIP pueden contener más de un flujo de medios. El concepto es similar a adjuntar varios archivos a un mensaje de correo electrónico. Por ejemplo, un mensaje INVITE enviado desde un cliente SIP a un servidor SIP puede tener los siguientes campos:

Junos OS admite hasta 6 canales SDP negociados para cada dirección, por un total de 12 canales por llamada. Para obtener más información, consulte Descripción de la ALG del SIP.

Escenario de TDR sip

Las figuras 2 y 3 muestran una INVITACIÓN de llamada del SIP y 200 OK. En la Figura 2, ph1 envía un mensaje de invitación sip a ph2. Observe cómo el dispositivo traduce las direcciones IP de los campos de encabezado(que se muestran en letra en bold).

La sección SDP del mensaje INVITE indica dónde está dispuesto a recibir los medios el llamador. Observe que el pinhole de medios contiene dos números de puerto, 52002 y 52003, para RTCP y RTP. La perforación vía/contacto proporciona el número de puerto 5060 para la señalización SIP.

Observe cómo, en el mensaje de respuesta 200 OK en la figura 3, las traducciones realizadas en el mensaje INVITE se invierten. Las direcciones IP de este mensaje, que son públicas, no se traducen, pero se abren puertas para permitir el acceso de la secuencia de medios a la red privada.

Figura 2: Escenario 1 de TDR sip

Figura 3: Escenario 2 de TDR sip

Clases de respuestas SIP

Las respuestas sip proporcionan información de estado sobre transacciones SIP e incluyen un código de respuesta y una frase de razón. Las respuestas sip se agrupan en las siguientes clases:

• Informativo (100 a 199): solicitud recibida, que continúa procesando la solicitud.

• Éxito (200 a 299): acción recibida, entendida y aceptada con éxito.

• Redirección (300 a 399): se requiere más acción para completar la solicitud.

• Error del cliente (400 a 499): la solicitud contiene una sintaxis incorrecta o no se puede cumplir en este servidor.

• Error del servidor (500 a 599): el servidor no pudo satisfacer una solicitud aparentemente válida.

• Falla global (600 a 699): la solicitud no se puede satisfacer en ningún servidor.

La Tabla 2 proporciona una lista completa de respuestas SIP actuales.

Modo TDR en modo IPv6 puro (NAT66) para SIP IPv6 ALG

El SIP IPv6 ALG es compatible con NAT66 al igual que NAT44. NAT66 (TDR IPv6) proporciona funciones TDR de origen y TDR estáticas similares a las de NAT44 (TDR IPv4).

TDR-PT

La traducción de protocolos de traducción de direcciones de red (TDR-PT) (RFC 2766) es un mecanismo de traducción de protocolos que permite la comunicación entre nodos solo IPv6 e IPv4 mediante traducción independiente de protocolos de datagramas IPv4 e IPv6, sin necesidad de información de estado para la sesión.

TDR-PT se implementa mediante TDR normal de dirección IPv6 a dirección IPv4 y viceversa. El SIP ALG procesa esas traducciones de direcciones en la carga del mismo modo que las direcciones se procesan en TDR normal.

NAT-PT enlaza las direcciones de la red IPv6 con direcciones en la red IPv4 y viceversa para proporcionar enrutamiento transparente para los datagramas que atraviesan entre los reinos de direcciones.

La principal ventaja de TDR-PT es que los dispositivos finales y las redes pueden ejecutar direcciones IPv4 o IPv6 y el tráfico se puede iniciar desde cualquier lado.

NAT64

NAT64 es un mecanismo para permitir que los hosts IPv6 se comuniquen con servidores IPv4. Nat64 es necesario para mantener la asignación de direcciones IPv6 a IPv4. Esta asignación de direcciones está configurada estáticamente por el administrador del sistema (traducción sin estado) o, con más frecuencia, se crea automáticamente cuando el primer paquete de la red IPv6 llega a NAT64 para ser traducido (con estado).

Nat64 se implementa en dispositivos mediante el uso de TDR persistente. Cuando el primer mensaje de solicitud sip (el primer paquete debe ser solo de IPv6) transversa el DUT, se crea el enlace de direcciones y, luego, los paquetes pueden fluir en ambas direcciones.

El mecanismo NAT64 traduce paquetes IPv6 a paquetes IPv4 y viceversa, lo que permite que los clientes IPv6 se comuniquen con los servidores IPv4 mediante UDP, TCP o ICMP de unidifusión. El comportamiento de TDR-PT y NAT64 parece similar, pero estos mecanismos se implementan de manera diferente.

Cuando se implementa NAT64 con TDR persistente, el SIP ALG con compatibilidad con IPv6 agrega la traducción TDR a la tabla de enlace TDR persistente si nat está configurada en la dirección del registro. Dado que el TDR persistente no puede duplicar la dirección configurada, no se admite la coexistencia de NAT66 y NAT64 configuradas en la misma dirección.

Solo se crea un enlace para la misma dirección IP de origen.

STUN y SIP ALG

Session Traversal Utilities for NAT (STUN) es una solución para hacer que VoIP funcione a través de TDR y firewall.

Anteriormente, STUN funcionaba sin el SIP ALG. Esto significa que el ALG del SIP no estaba involucrado cuando se configuró TDR persistente.

LA STUN puede coexistir con el ALG del SIP y el ALG del SIP está involucrado cuando se configura el TDR persistente.

Descripción de la compatibilidad con llamadas ALG entrantes del SIP mediante el registro y el TDR de SIP

El registro del Protocolo de iniciación de sesión (SIP) proporciona una capacidad de descubrimiento mediante la cual los proxys y servidores de ubicación del SIP pueden identificar la ubicación o las ubicaciones en las que los usuarios quieren ser contactados. Un usuario registra una o más ubicaciones de contacto mediante el envío de un mensaje REGISTER al registrador. Los campos To y Contact del mensaje REGISTER contienen el identificador de recurso uniforme (URI) de dirección de registro y una o más URI de contacto, como se muestra en la figura 4. El registro crea enlaces en un servicio de ubicación que asocia la dirección de registro con la dirección o direcciones de contacto.

El dispositivo monitorea los mensajes DE REGISTRO salientes, realiza la traducción de direcciones de red (TDR) en estas direcciones y almacena la información en una tabla TDR entrante. Luego, cuando se recibe un mensaje INVITE desde fuera de la red, el dispositivo utiliza la tabla TDR entrante para identificar a qué host interno enrutar el mensaje INVITE. Puede aprovechar el servicio de registro de proxy SIP para permitir llamadas entrantes mediante la configuración de grupos TDR o TDR de origen de interfaz en la interfaz de salida del dispositivo. El TDR de origen de interfaz es adecuado para el manejo de llamadas entrantes en una oficina pequeña, mientras que recomendamos configurar conjuntos TDR de origen para redes más grandes o un entorno empresarial.

Nota:

La compatibilidad con llamadas entrantes mediante TDR de origen de interfaz o un grupo TDR de origen solo se admite para servicios SIP y H.323. En el caso de las llamadas entrantes, Junos OS admite actualmente solo UDP y TCP. Actualmente no se admite la resolución de nombres de dominio; por lo tanto, las URI deben contener direcciones IP, como se muestra en la figura 4.

Figura 4: Uso del registrador de SIP