SIP — Introducción

El protocolo de inicio de sesión (SIP) ofrece una interfaz adicional para la integración de sistemas de productos de seguridad. El protocolo SIP está ampliamente aceptado en el sector de las telecomunicaciones y aporta más flexibilidad para la interconexión y los usos cotidianos. Integradores de sistemas, desarrolladores y usuarios finales reclaman interfaces abiertas y estandarizadas, ya que les aportan un mayor valor al permitir el uso de los productos en diferentes sistemas. Los productos Axis compatibles con SIP están pensados para usos tanto de soluciones de seguridad como de soluciones de comunicación.

La configuración de un sistema SIP puede resultar extremadamente sencilla. Sin embargo, en el caso de estructuras de red complejas o en situaciones que exijan un plus de seguridad o funciones adicionales de gestión de llamadas, es necesario utilizar servidores SIP y técnicas de NAT traversal, que requieren unos conocimientos técnicos más avanzados por parte del instalador o el técnico.

El protocolo de inicio de sesión (Session Initiation Protocol, SIP) se utiliza para iniciar, mantener y finalizar sesiones multimedia entre distintas partes. Estas sesiones normalmente son de audio, pero a veces incluyen también vídeo. SIP es el protocolo estándar utilizado en aplicaciones de voz sobre IP (VoIP) y plataformas de Comunicaciones Unificadas (CU); consulte la sección 3).

SIP es una forma de conectar, integrar y controlar sus productos de red de Axis. Es compatible con todos los altavoces de red Axis, todos los intercomunicadores de red Axis y determinados dispositivos de sistema y cámaras Axis.

Para la comunicación a través de SIP, se necesitan al menos dos clientes SIP. Un cliente SIP puede ser un teléfono físico SIP, un softphone, un cliente móvil o un producto Axis compatible con SIP.

Cada cliente SIP tiene asignada su propia dirección SIP. Una dirección SIP es similar a una dirección de correo, pero con el prefijo “sip:”.

Por ejemplo, sip:bob@axis.com [sip:<usuario@]<proveedor>. Este identificador puede utilizarse en diferentes dispositivos y es similar a un número de teléfono vinculado a una tarjeta SIM, que puede usarse en varios dispositivos.

Un sistema SIP puede tener muchas formas. En su versión más sencilla, el sistema consta de dos agentes de usuario de SIP o más que se comunican directamente entre sí. Este modelo suele conocerse como configuración peer-to-peer, configuración de llamada directa o configuración local. En este caso, la dirección SIP suele tener el formato sip:<ip-local>, por ejemplo sip:192.168.0.90

Para realizar una llamada peer-to-peer de un agente de usuario a otro de la red local, solo hace falta la dirección SIP que contiene la dirección IP de la unidad.

Una infraestructura VoIP basada en SIP es fácilmente escalable. El siguiente paso en tamaño es utilizar un servidor SIP, o centralita privada (PBX), como concentrador. Los agentes de usuario de SIP se registran en el servidor de registro y luego contactan con otros agentes de usuario marcando una extensión en la centralita privada.

En este caso, una dirección SIP típica tendría este formato:<usuario>@<dominio>. Otra opción sería sip:<usuario>@<ip-servidor de registro>, por ejemplo sip:6007@ miservidorsip.net. Una centralita privada funciona como una central telefónica tradicional, que muestra el estado actual de los clientes y ofrece servicios como la transferencia de llamadas, buzón de voz y redireccionamientos, entre otros.

Un servidor SIP suele incluir un proxy, un servidor de registro y función de redireccionamiento. Los proxies dirigen las llamadas y aportan información lógica adicional a las llamadas entrantes. Los servidores de registro aceptan solicitudes de registro y actúan como servicio de localización del dominio que gestionan. Los servidores de redireccionamiento redirigen el cliente para contactar con una dirección SIP alternativa.

El servidor SIP puede configurarse como elemento local o puede estar deslocalizado. Puede alojarse en las instalaciones o en la nube. Al realizar llamadas SIP entre diferentes sitios, normalmente las llamadas se enrutan a través de diferentes proxies SIP. Estos proxies consultan la ubicación de la dirección SIP de destino.

Para poder usar su dispositivo con un servidor SIP. debe crear una cuenta en el servidor con un ID de usuario y una contraseña determinados. Para registrar su dispositivo en el servidor, debe configurar una cuenta en el dispositivo introduciendo la dirección del servidor, el ID de usuario y la contraseña.

Usando un troncal SIP, los agentes del usuario de SIP pueden vincularse a una red de telefonía tradicional (PSTN). Eso abre la puerta a asignar un número de teléfono normal al agente de usuario de SIP.

El troncal SIP basado en la nube es un enfoque moderno que aprovecha internet para ofrecer llamadas y otros servicios de comunicación. Este método permite prescindir de las líneas telefónicas físicas, lo que facilita la integración con soluciones en la nube y sistemas VoIP.

Ejemplo: Usando un troncal SIP (1) con un proveedor de servicio, puede asignar números de teléfono externos a sus dispositivos (2, 3). Esto permite realizar llamadas entre un altavoz de red o un intercomunicador de red y teléfonos tradicionales (4).

Al utilizarlo con un troncal SIP, el dispositivo se conecta al servidor del modo descrito arriba.

Las comunicaciones unificadas (CU) hacen referencia a la integración de diversas herramientas y tecnologías de comunicación en un sistema único y cohesionado. SIP desempeña un papel vital en las CU al hacer posible una interacción fluida entre distintos canales de comunicación, como voz, vídeo, mensajería instantánea e información de presencia. Gracias al uso del protocolo SIP, las organizaciones pueden crear un entorno de comunicaciones unificado que potencie la colaboración, mejore la productividad y proporcione una experiencia de usuario coherente en múltiples dispositivos y plataformas.

Las CU pueden proporcionarse localmente en soluciones in situ o a través de soluciones en la nube (CU como servicio, o UCaaS). Algunos ejemplos de proveedores de servicios para las soluciones en la nube son Cisco Webex, Microsoft Teams y Zoom.

Para hacer una llamada SIP, se realizan varios pasos para intercambiar información entre los UA que inician y reciben la llamada.

Al iniciar una llamada, el UA iniciador (1) envía una solicitud o INVITACIÓN a la dirección SIP del UA destinatario (2). La INVITACIÓN contiene texto del Protocolo de descripción de sesión (SDP), en el que se describen los formatos multimedia disponibles y la información de contacto del iniciador de la llamada.

Tras recibir la INVITACIÓN, el destinatario confirma su recepción inmediatamente con una respuesta “100 TRYING”.

A continuación, el agente de usuario compara los formatos de contenidos descritos en el SDP con los suyos. Si se puede determinar un formato común, el agente de usuario indica al destinatario que hay una llamada entrante y envía una respuesta provisional, “180 RINGING”, al agente de usuario iniciador.

Cuando el destinatario responde a la llamada, se envía una respuesta “200 OK” al iniciador, para confirmar que se ha establecido la conexión. Esta respuesta contiene un SDP negociado en el que se indica al iniciador qué formato de contenido se debe usar y a dónde se deben enviar las transmisiones multimedia.

En ese momento, se configuran las transmisiones multimedia negociadas mediante el Protocolo de transporte en tiempo real (RTP), con parámetros basados en el SDP negociado, y los contenidos se transmiten directamente entre las dos partes. El iniciador envía una confirmación (ACK) a través de SIP para confirmar que ha configurado las transmisiones de contenido como se acordó. La sesión de SIP sigue activa, pero no participa en la transferencia de contenidos.

Cuando una de las partes decide finalizar la llamada, envía una nueva petición, en este caso BYE. Al recibir una petición BYE, la parte receptora responde con un “200 OK” y se detienen las transmisiones de contenidos RTP.

El protocolo de descripción de sesión (SDP) es un protocolo para describir los parámetros de inicialización de contenidos transmitidos. El texto SDP contiene información sobre qué formatos de contenidos (esto es, códecs) admiten los clientes y el orden preferido de selección de códec de los clientes.

Los códecs de audio más habituales para las llamadas SIP son PCMU, PCMA, G.722, G.726 y L16. Si tanto el iniciador como el destinatario admiten diferentes códecs solapados, normalmente se seleccionará el códec con la prioridad más alta en el lado del receptor. La selección de códecs afecta al ancho de banda, por lo que debe tenerse muy en cuenta para cumplir con los requisitos de compatibilidad con otros UA SIP y mantener unos requisitos de ancho de banda adecuados para cada caso. Por ejemplo, en una red local en la que todos los clientes admiten L16, el audio sin comprimir es una buena opción. Sin embargo, si va a accederse al UA SIP a través de internet usando un teléfono móvil, PCMU es una opción mejor.

Si la configuración de la infraestructura SIP es compleja, el inicio es algo distinto, porque la sesión de SIP se configura paso a paso para cada salto. Sin embargo, una vez configurada la sesión SIP, el tráfico normalmente no se enruta, sino que viaja directamente entre las diferentes partes, como en el ejemplo anterior.

La multifrecuencia de dos tonos (MFDT o DTMF) es un formato empleado para enviar información a través de una conexión telefónica. Las señales MFDT pueden enviarse en llamadas SIP y usarse para proporcionar instrucciones a un dispositivo SIP. Los caracteres que pueden utilizarse con la MFDT son los números de 0 a 9, las letras de A a D, * y #.

Por ejemplo, en una llamada a un portero automático con SIP, podría enviarse el carácter MFDT 5 desde el teclado del teléfono, configurado para que el receptor lo interprete como un comando para desbloquear la puerta.

Hay tres formas diferentes de enviar MFDT en una llamada SIP:

• El método tradicional dentro de banda, en el que la señal es en realidad un impulso de audio entrelazado con el flujo de audio. Sin embargo, es poco fiable y solo funciona con códecs sin comprimir.

• El método SIP INFO, en el que el carácter MFDT se envía en un mensaje SIP en el flujo de señalización. Es un método muy fiable y fuera de banda, pero su compatibilidad es limitada.

• El método RTP (RFC2833), en el que el carácter MFDT se codifica como paquete RTP y se envía fuera de banda. Es el procedimiento más aceptado y cuenta con una buena compatibilidad.

Los entornos de red complejos, como las redes de empresa, pueden plantear dificultades cuando se utiliza SIP. Y lo mismo vale cuando quiere utilizar cifrado.

En un entorno de red más complejo, tal vez sea necesario utilizar la traducción de direcciones de red (Network Address Translation o NAT). La tecnología NAT es una representación pública de direcciones IP pertenecientes a una red local privada. Por tanto, todas las unidades de una subred privada comparten un prefijo de dirección IP común, por ejemplo 192.168.1.XXX. Esta es la dirección que utilizan al comunicarse entre sí. Cuando se comunican con otra red, esta dirección se convierte en la dirección pública del router, a las que se añade la asignación de puerto.

• 192.168.1.24 => 184.13.12.33:44221

• 192.168.1.121 => 184.13.12.33:24325, y así sucesivamente.

Como la tabla de traducciones se almacena en el router, en la mayoría de los casos un usuario externo no puede conocer la dirección de un dispositivo al que se ha aplicado NAT. Durante la comunicación por SIP, esto puede generar uno de los problemas siguientes:

• Imposibilidad de iniciar, actualizar o finalizar una sesión, esto es, no es posible llamar, retener una llamada o colgar.

• No hay flujos de contenido.

• Flujos de contenido unidireccionales.

Para resolver estos problemas, SIP permite utilizar tres técnicas de NAT diferentes:

• STUN: un sistema para preguntar a un servidor de un lugar conocido cuál es la dirección pública de la unidad. El servidor STUN comunica la IP pública y la asignación de puertos utilizada para realizar la petición. El resultado se utiliza después en la señalización y la transferencia de contenidos, y la solución funciona en la mayoría de las situaciones.

• TURN: cuando se usa TURN, todo el tráfico pasa a través de un servidor conocido. Esta solución implica un coste extra, ya que la máquina en la que se aloja el servidor TURN debe tener suficiente potencia para enrutar todos los contenidos para cada cliente usando el servicio. Se trata de una solución más cara, pero puede ser útil en algunas situaciones en las que STUN no funciona.

• ICE: el protocolo ICE recopila todas las direcciones IP que puede encontrar en relación con un UA SIP e intenta calcular cuál debe usarse. Si se utiliza en combinación con STUN y TURN en el UA SIP iniciador y receptor aumenta las probabilidades de que las llamadas SIP se establezcan correctamente.

El tráfico de señalización SIP normalmente se envía a través del protocolo UDP sin conexión. También puede enviarse a través de TCP, en cuyo caso también puede cifrarse utilizando la seguridad de la capa de transporte (TLS).

Para garantizar que se utiliza una conexión segura para una llamada, el protocolo SIP utiliza un esquema de direccionamiento conocido como SIP seguro (SIPS), que requiere configurar el modo de transporte en TLS. Al realizar una llamada, se añade a la dirección SIP marcada el prefijo “sips:” en lugar de “sip”. Por ejemplo, sips:bob@biloxi.ex.com en lugar de sip:bob@biloxi.ex.com. De este modo, cada salto debe estar protegido mediante TLS y requiere del extremo receptor el uso del mismo nivel de seguridad. Al llamar a una dirección con prefijo sip al utilizar solo TLS se garantiza que el primer salto está cifrado.

Para obtener el máximo nivel de seguridad, deben adoptarse las siguientes medidas:

• El modo de transporte debe ajustarse en TLS.

• El prefijo sips debe utilizarse en todo momento.

• Debe utilizarse SIP INFO para enviar tonos MFDT, ya que se envían por el canal cifrado.

Recuerde que no todos los clientes son compatibles con SIP seguro.