SIP

Para definir y concretar acerca del protocolo SIP (Session Initiation Protocol, o Protocolo de Inicio de Sesiónes), sería viable diseñar una Wiki específica en la que poder detallar todo lo referente al mismo, desde su historia, su(s) RFC(s) (RFC 3261, y sucesivos para numerosas extensiones del mismo), sus usos, proxies y software especifico como Kamailio y OpenSIPS, de hecho Digium difunde cursos específicos sobre este protocolo para su máximo entendimiento y aprovechamiento.

En esta primera aproximación, no vamos a tratar este protocolo con tanta profundidad como quizá exige, pero existe numerosa bibliografía al respecto, y concretamente apunto a una por cercanía con respecto a la idea subyacente de este proyecto de AsteriskWIKI

Digamos que la mayor parte de las conexiones que se realizan entre estaciones, pasarelas y dispositivos de telefonía IP en general, que no contienen Asterisk en esencia, con respecto a nuestra máquina, están basadas en el protocolo SIP.

Conceptos Básicos

Es muy importante tener presentes algunos conceptos básicos sobre el protocolo SIP para poder entender como funciona todo, y en esencia incluso, poder tratar futuros problemas que pudieran derivar de un error de configuración, o incluso, de interconexión entre terminales de cualquier índole.

Relación entre SIP y Asterisk

Existe una mala concepción sobre como funciona realmente el SIP porque es común pensar que es encargado de llevar los datos multimedia, así como los mensajes de sesión conjuntamente. Parte de esta afirmación es cierta, concretamente la segunda parte, dado que este protocolo fue diseñado exclusivamente como sistema de señalización conjuntamente a otro flujo de datos multimedia a través de un protocolo simultáneo (que en Asterisk sería el protocolo RTP, Protocolo de Transporte en Tiempo Real, o Real-Time Tranport Protocol). Además para "complicar" el concepto, durante la trasmisión también interviene un tercer protocolo "familiar" de SIP llamado SDP (Protocolo de Descripción de Sesiones, o Session Description Protocol), redactado en el RFC 4566 y embebido dentro del protocolo SIP por lo que no consumiría más recursos (por ejemplo Puertos a nivel TCP/IP), y se encargaría de enriquecer el mensaje entre sesiones necesario para la trasmisión eficaz entre los dispositivos.

Realmente SIP no es capaz de ofrecer un servicio por si mismo, pero contiene los mensajes primitivos para poder implementar los servicios subyacentes sobre el mismo. Por eso, SIP curiosamente, no tiene nada que ver realmente con la telefonía en si, solo podría considerarse un estándar cualquiera de entendimiento entre dispositivos, algo que realmente todavía no se ha asentado, ya que múltiples dispositivos, aun no siguen los estándares "impuestos" dentro de los RFC, ya que aun no ha madurado hasta la categoría de estándar IEEE.

SIP se popularizo, debido que en el momento de la implementación de servicios de telefonía IP, no existían realmente grandes competidores en este aspecto. Además la seguridad utilizando SIP no prima especialmente, debido a que la trasmisión se realiza con mensajes de texto, y para encriptar la información es fundamental recurrir a extensiones independientes que transforman los mensajes en ambos nodos.

En el año 2010 nació como RFC 5456 un verdadero competidor, IAX, pero demasiado tarde, ya que el mercado de las telecomunicaciones IP (y concretamente dispositivos y productores), ya se había asentado sobre el protocolo SIP.

Funcionamiento Esencial

Flujo Mensajes SIP

SIP en la capa de transporte OSI, puede trabajar tanto con puertos TCP como UDP, y de hecho UDP suele ser elegido regularmente. El puerto de elección más común y estandarizado es el 5060, y como comentábamos con anterioridad, a través del mismo, también se trasmiten los mensajes del protocolo SDP.

Por otro lado, para trabajar con Audio en Asterisk tenemos que utilizar forzosamente el protocolo RTP para llevar el tráfico. Para cada canal de audio es necesario trabajar con un puerto independiente, y esto acarreara aún mas problemas en la seguridad, o en la interoperatividad con nuestro sistema. Veremos soluciones más adelante para salir del paso, ninguna bajo mi criterio, especialmente excepcional.

Los mensajes clásicos de SIP son los siguientes:

• INVITE
• REGISTER
• ACK
• BYE
• OPTIONS

En la imagen, podemos ver un flujo clásico de mensajes entre un servidor Asterisk y dos teléfonos conectados al mismo.

Problemas derivados de SIP y Asterisk

Siguiendo la linea, existen una serie de problemas que derivan del uso de SIP con nuestra máquina Asterisk, cuando tratamos de acceder al exterior (concretamente a Internet), de manera bidireccional. Supongamos que tenemos un teléfono conectado a nuestro servidor Asterisk, y a su vez, nuestro servidor Asterisk quiere comenzar a trasmitir datos con otro servidor SIP externo, o también la posibilidad que un teléfono fuera de nuestra red local, desea conectar a nuestro servidor Asterisk y trasmitir audio bidireccionálmente con uno de los teléfonos ubicados dentro de la red y también conectado a este servidor en cuestión.

Nos vemos ante dos problemas con sus respectivas soluciones:

• Problemas con el NAT
• Problemas con los puertos

Problemas con el NAT

Si viviéramos en un mundo IPv6 esto eventualmente no sucedería, pero como estamos de alguna forma supeditados al uso de un NAT sobre otro NAT sobre otro NAT, etc, etc dado que poseemos un número excesivamente limitados de direcciones IPv4 nos encontramos ante el primer problema.

Tenemos un Router con conexión a internet, y asignada una dirección IP concreta. Dentro de la red local de ese router, nuestra máquina posee una dirección local. En las cabeceras SIP al enviar el paquete de iniciación de sesión a través del router, el servidor remoto por defecto, registraría nuestro equipo apuntando a la dirección local, y por consiguiente, no existiría una ruta de regreso para seguir la trasmisión de mensajes y que se complete la "transacción" adecuadamente.

Si nuestro router posee funciones "avanzadas" para la gestión del nat, si en nuestra configuración de Asterisk, en el fichero de configuración del protocolo SIP marcamos que nos debemos registrar activando una propiedad especifica (nat=yes), Asterisk implementaría una función exclusiva para resolver este problema forzando el comportamiento descrito en el RFC 3581 y adicionalmente, habilitando el soporte para el RTP Simétrico, aparte que es fundamental que el router posea capacidades de NAT Transveral e implemente los correspondientes ALG

Problemas con los puertos

Este es el escenario más clásico perpetuado por el uso del protocolo RTP, el cual utiliza puertos aleatorios y muy difícilmente controlables (o al menos todo intento de control provoca en última instancia fallos en la comunicación debidos a su relativa aleatoriedad).

Por un lado, nos encontramos lo clásico: necesitamos abrir puertos en nuestro Cortafuegos para permitir el paso de datos por uno o varios determinado en concreto.

Para el caso de SIP/SDP no hay problema, porque si hemos elegido el puerto por defecto 5060, simplemente con abrir este, ya permitiriamos el paso y podríamos ver en nuestro registro de eventos, el intercambio de mensajes satisfactoriamente. Realizamos la llamada, vemos con salen los mensajes ACK, INVITE, OK... suenan los teléfonos, descolgamos y nos damos cuenta de pronto que no hay voz. Los datos RTP estan siendo bloqueados en el Cortafuegos. La pregunta es ¿que puerto debemos desbloquear ahora para permitir el paso?

Existen tres formas de planteárselo:

• Abrir todos los puertos necesarios según configuración en el fichero correspondiente (rtp.conf). A nivel de seguridad es una idea nefasta.
• Utilizar un servidor VPN (Virtual Private Network) al que conectaría nuestro dispositivo remoto, y una vez dentro, ya se establecería la conexión como si formara parte de la red local. La inconveniencia principal esta basada en cuestiones de rendimiento, aunque resulta relativamente popular.
• Trabajar con un servidor STUN RFC 3489. Esta solución es quizá la mas compleja y existen múltiples fuentes de documentación que tratan específicamente sobre ella.

Véase también

• Seguridad

Enlaces Externos

• Kamailio y OpenSIPS los dos SIP Proxy más populares.