Voz sobre IP: Fundamentos de la señalización mediante el protocolo SIP

En cualquier sistema telefónico es necesario un protocolo de señalización. La misión de la señalización es permitir el intercambio de información entre los usuarios y la red, a fin de que la llamada pueda ser establecida y posteriormente, terminada.  En la telefonía analógica la señalización está formada por:

• Detección de intensidad por el bucle local para saber cuando el usuario ha descolgado para efectuar una llamada y cuando ha colgado al finalizar la llamada
• Tonos desde la central hacia el usuario: Tono de invitación a marcar, tono de progreso de llamada, tonos de notificación de congestión en la red, usuario ocupado, etc.
• Señal de ring desde la central hacia el teléfono llamado. Usualmente es una señal senoidal de 75 voltios eficaces y 25 Hz
• Marcación por parte del usuario llamante del número deseado, ya sea mediante el sistema de pulsos, hoy en día prácticamente fuera de uso, o por tonos (DTMF).
• Cambios de polaridad desde la central hacia el bucle del usuario, para indicar el estado de la llamada

En el siguiente gráfico se muestra el proceso de señalización para una llamada mediante la telefonía analógica:

En el caso de la telefonía RDSI la señalización es, al igual que el transporte de la voz, totalmente digital. Tanto la red RDSI como los teléfonos RDSI intercambian una serie de paquetes digitales denominados mensajes, teniendo cada uno de ellos un significado distinto. Así, una llamada como la mostrada anteriormente sobre una línea analógica, si es sobre RDSI, tendría una señalización de acuerdo al siguiente diagrama:

Cuando uno de los terminales desea finalizar la comunicación, la señalización intercambiada es la mostrada en el diagrama inferior:

Cada uno de estos mensajes tiene una estructura similar, con un contenido útil en lo que técnicamente se denomina capa 3 y estando ese contenido útil insertado dentro de una trama o capa 2, donde aparece la dirección de destino de la trama y además hay unos bytes de detección y corrección de errores. En el caso del mensaje de SETUP su estructura interna es la siguiente:

Vemos que un mensaje de este tipo se compone de una secuencia de bytes, comenzando por un byte de inicio o Start Flag y que siempre es el 01111110. El mensaje termina cuando aparece un byte similar al final del mismo, el byte denominado End Flag. En el interior del mensaje, dentro de la denominada capa 3 o Layer 3 cada uno de los bytes tiene un significado que tanto la red RDSI como los terminales RDSI entienden.  Es preciso señalar que no todos los mensajes tienen el mismo tamaño, ya que otros mensajes tienen que comunicar mucha menos información que este mensaje de SETUP. Por ejemplo, en el caso del mensaje de Call Procceding su contenido interno es el siguiente:

Se observa que este mensaje es idéntico al de SETUP en lo que concierne a la capa 2 pero con un contenido de capa 3 mucho menor. Si examinamos otro mensaje, como el mensaje de Alerting, vemos que la estructura se repite:

La señalización digital tiene grandes ventajas sobre la señalización analógica. Por ejemplo, en la señalización digital  se pueden añadir fácilmente nuevos mensajes de señalización simplemente modificando el software tanto de los terminales RDSI como de la red RDSI y con ello se pueden implementar fácilmente nuevos servicios. De hecho, la RDSI cuenta desde su comienzo (1992) con servicios suplementarios que en la telefonía analógica no ha sido posible incorporar hasta muchos años después. La RDSI cuenta además con otros valiosos servicios suplementarios que la telefonía analógica no tiene ni tendrá nunca (los números DDI, por ejemplo).  En la telefonía analógica cualquier cambio en la señalización obliga a sustituir todos los terminales telefónicos y a renovar todas las centrales telefónicas del operador.

Y con esto llegamos a la telefonía IP donde las comunicaciones se realizan por redes IP privadas o redes IP públicas como es la propia Internet.

Una vez expuesto lo anterior, se entiende sin dificultad que para que dos terminales IP puedan establecer una comunicación es necesaria una señalización. Esta señalización se puede efectuar mediante diferentes protocolos, pero hoy en día el protocolo más utilizado es SIP, cuyo significado es Session Initiation Protocol o protocolo de inicio de sesiones. Este protocolo ha sido desarrollado por el denominado Internet Engineering Task Force (IETF) y se ha convertido en un auténtico estándar dentro de la telefonía IP. Al igual que sucede con la señalización en la telefonía analógica o en la telefonía RDSI, el protocolo SIP se encarga únicamente de la señalización, no del transporte de la voz. El transporte de la voz o del vídeo en su caso se realiza siempre mediante el protocolo RTP (Real Time Protocol), que es uno de los protocolos de la pila TCP/IP.

SIP ha tenido diferentes versiones y la que está actualmente en vigor es la denominada SIP/2.0 (2002). SIP es un protocolo que además de ser utilizado en la telefonía IP también es usado en la señalización de transmisiones multimedia, como videoconferencias y es usado igualmente en la señalización para la transmisión de contenidos multimedia en los sistemas de telefonía móvil de 3ª y 4ª generación, UMTS y LTE respectivamente. De nuevo se insiste en que, SIP no se encarga de transportar ni la voz ni los contenidos multimedia, solo se encarga de la señalización. La voz y los contenidos multimedia habitualmente se transmiten mediante el protocolo RTP, tal y como muestra el siguiente diagrama:

La señalización se hace mediante SIP, pero existen otros protocolos como son el H.323, MGCP y Megaco. Estos protocolos utilizan paquetes TCP por lo que la propia red IP se encarga de que la información enviada llegue correctamente a su destino. SIP en cambio aunque puede utilizar paquetes TCP también puede mandar la señalización mediante paquetes UDP, por lo que será la propia aplicación la que tendrá que verificar que el paquete recibido es correcto o en su caso, solicitar una retransmisión. Se observa en el diagrama anterior que SIP no se encarga de la calidad del servicio ya que de esto se encargan protocolos como RSVP y RTCP. Por último y como ya se ha indicado, el transporte de audio y de contenidos multimedia queda en manos del protocolo RTP, el cual se transmite a su vez en paquetes UDP, es decir, no se comprueba que los paquetes han llegado correctamente al destino.

El protocolo SIP es de tipo request-response o protocolo de petición-respuesta, donde los clientes envían una petición a los server y estos envían la respuesta correspondiente en cada caso. En una llamada SIP cada uno de los elementos que interviene puede tomar el rol de cliente o de servidor indistintamente, según la fase de señalización donde se encuentre la llamada. 

En el diagrama anterior se muestra el establecimiento de una llamada entre dos teléfonos mediante el protocolo SIP y en modo peer-to-peer, sin ningún tipo de servidor en medio. Cuando uno de los teléfonos envía un mensaje hacia el otro, se comporta como un cliente. Cuando el teléfono que recibe un mensaje envía la respuesta o respuestas correspondientes, se comporta como un server. Como se observa en el diagrama, un teléfono adopta a veces el papel de cliente y otras veces el de server.

Aunque SIP permite establecer llamadas en modo peer-to-peer, ese procedimiento requiere conocer la dirección IP del otro extremo por lo que en la práctica se utilizan los denominados SIP Server. Estos equipos se encargan del registro de cada uno de los teléfonos SIP y por tanto conocen la dirección IP que tiene cada teléfono en todo momento. Cuando un SIP server resuelve la dirección IP de cada equipo que participa en la llamada, se convierte acto seguido en un SIP proxy, enviando la señalización entre los teléfonos a través suyo. Un SIP Server siempre esta activo y se encarga de registrar y de actualizar cuando es necesario la localización de los dispositivos SIP. Un SIP Server también se encarga de responder a un usuario SIP cuando realiza una llamada a otro dispositivo SIP que está apagado. Aunque la función de SIP register y de SIP Proxy puede ser implementada en equipos físicos diferentes, a menudo se encuentran en un mismo equipo, el SIP Server.

Como se observa en el diagrama anterior, la transmisión de los contenidos RTP se realiza directamente entre los equipos que forman parte de la conversación o llamada, sin utilizar el SIP Server. Este diseño es debido a una simple cuestión eficacia, ya que si se envían cientos o miles de tramas de voz a través de un SIP Server, es muy probable que dicho equipo se encuentre colapsado, impidiendo una comunicación fluida entre extremos. Por otro lado, es preciso señalar que el protocolo SIP está orientado a texto y es un protocolo muy ligero, por lo que un solo SIP Server puede atender sin dificultad la señalización de miles de llamadas por segundo.

Nota técnica: Aunque en el esquema anterior solo aparece un SIP Server entre los dos equipos que realizan la comunicación, en la práctica puede darse el caso de que sean necesarios varios SIP Server para poder establecer la señalización entre los equipos.

Una vez vistos los fundamentos de SIP, es el momento de comentar con un poco más de detalle su estructura interna y otros aspectos igualmente interesantes. SIP es un protocolo muy vinculado a Internet y de alguna manera es un híbrido entre dos protocolos muy utilizados en Internet, el protocolo SMTP, utilizado en servidores de correo electrónico y el protocolo HTTP, utilizado en el envío de páginas web entre los servidores web y los clientes (normalmente, los clientes son los navegadores).

Funcionamiento del protocolo HTTP (developer.mozilla.org)

HTTP es la base de cualquier intercambio de datos en la Web y, al igual que SIP, es un protocolo de estructura cliente-servidor. En el protocolo HTTP una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así, una página web completa resulta de la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetación de la página web (CSS), el texto, las imágenes, vídeos, scripts, etc… El protocolo SIP copia el funcionamiento de HTTP, con el uso de mensajes de peticiones y de respuestas, y con el contenido de los diferentes mensajes “en inglés”, para que puedan ser leídos fácilmente y poder detectar errores si los hubiera. El protocolo H.323 en cambio es similar al protocolo utilizado en RDSI, donde el contenido de los mensajes es un conjunto de valores binarios, difíciles de leer y menos amigables a la hora de detectar errores.

El protocolo SIP coge del protocolo SMTP algo tan conocido como los campos From y To para indicar quien envía la señalización y a quien se envía:

Como se observa en el diagrama anterior, en el protocolo SIP hay peticiones (request) y respuestas (response). En ambos casos se utilizan los campos “From” y “To” para indicar el origen y el destino. Un mensaje SIP siempre tiene una cabecera (message header) y en algunos casos puede tener un cuerpo o contenido (message body) separados únicamente por una línea en blanco. Se observa también que SIP utiliza unas direcciones similares a las utilizadas en el correo electrónico, aunque siempre se escriben en un formato con el termino “sip:” por delante, tal y como se muestra en el siguiente ejemplo:    sip:alice@example.com. Al igual que sucedía con la señalización RDSI donde había diferentes mensajes para las diferentes fases de la señalización, SIP consta también de diferentes mensajes para las diferentes fases de la señalización. Inicialmente se crearon únicamente seis mensajes SIP pero posteriormente se han añadido otros nuevos mensajes para dotar de mayor funcionalidad al protocolo:

Un mensaje INVITE tiene un contenido interno como el mostrado a continuación.

INVITE sip:13@10.10.1.13 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK343bf628;rport
From: “Test 15” <sip:15@10.10.1.99>;tag=as58f4201b
To: <sip:13@10.10.1.13>
Contact: <sip:15@10.10.1.99>
Call-ID: 326371826c80e17e6cf6c29861eb2933@10.10.1.99
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Wed, 06 Dec 2009 14:12:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
  SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 258 

v=0
o=root 1821 1821 IN IP4 10.10.1.99
s=session
c=IN IP4 10.10.1.99
t=0 0
m=audio 11424 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off – – – –
a=ptime:20
a=sendrecv

En el mensaje anterior, el primer bloque corresponde a la cabecera o message header. Separado por una línea en blanco está el cuerpo del mensaje o message body. En este cuerpo del mensaje se encuentra información fundamental para la realización de la llamada mediante el denominado protocolo SDP (Session description protocol), el cual consta de los siguientes campos de información:

• Tiempo que la sesión está activa
• Medios utilizados en la sesión (codecs de audio, de vídeo, etc)
• Información acerca del ancho de banda necesario
• Información de contacto de la persona responsable

Cada uno de los campos del protocolo SDP tiene la estructura de <código de campo>=<valor>. Los códigos de campo siempre se identifican por una única letra y los más frecuentes se indican en el siguiente listado:

• v = versión del protocolo
• 0 = propietario de la sesión y su identificador
• s = nombre de la sesión
• t = tiempo en que la sesión está activa, en formato <t de comienzo><t de finalización
• m = medio utilizado, puerto, transporte y formato. El “medio” siempre es audio o   vídeo, el transporte es usualmente “RTP/AVP” indicando que se utilizará el protocolo RTP con un perfil para conferencias de audio y vídeo. El código “0” que sigue a continuación indica el uso del códec G.711 uLaw. El código “8” indica el uso del codec G.711 ALaw. El código “3” indica el uso del códec GSM y el código “18” indica el uso del códec G.729.
• a = utilizado para diferentes atributos de la sesión.

Los terminales SIP pueden además generar determinadas respuestas a cada uno de estos seis “métodos” o mensajes. Algunas de las respuestas son de confirmación, otras son para notificar que se está procediendo con la petición y otras más son para indicar alguna causa de error. En el siguiente diagrama se muestran algunas de las posibles respuestas:

Con los seis mensajes y las respuestas correspondientes se realizan las diferentes fases de señalización en comunicaciones mediante el protocolo SIP. En el siguiente diagrama se muestra el intercambio de mensajes correspondiente a la realización de una llamada entre dos terminales SIP, uno de ellos con  el número de extensión 121 y el otro con el 122:

Cuando una de las extensiones comunica a la otra que quiere finalizar la llamada, también se produce un intercambio de mensajes y de respuestas. En este caso, al igual que sucedía en la señalización RDSI, el proceso es más simple que en el establecimiento de la llamada:

Previamente a cualquier llamada o comunicación a través de SIP, es necesario que los equipos SIP estén registrados en el SIP Register, que como ya se ha indicado, normalmente está implementado en el propio SIP Server.

Es necesario tener en cuenta que en el proceso de registro le será solicitada al terminal SIP un password para confirmar dicho registro. Ese password nunca es enviado en forma de “texto plano” por la red, sino que es enviado de forma encriptada mediante un sistema de hash. Al mismo tiempo, cuando el servidor confirma el registro mediante la respuesta OK también le comunica mediante el parámetro Expires el número de segundos durante los cuales será válido dicho registro. Pasado ese tiempo, el terminal SIP necesitará registrarse de nuevo en el servidor.

Problemas con SIP: El protocolo SIP, al utilizar redes IP está sujeto a los problemas habituales de las redes IP y en especial a los problemas que surgen debido al uso de direcciones IP privadas. Entre los problemas más frecuentes se pueden citar los siguientes:

1. Problemas con los Firewalls: Los cortafuegos a menudo impiden a dos equipos SIP la recepción de tráfico entrante o saliente RTP o incluso la propia señalización SIP. La única solución para que la VoIP mediante SIP funcione correctamente es identificar correctamente que puertos TCP/UDP deben ser abiertos. En cuanto a la señalización SIP no suele haber especiales problemas puesto que se utilizan puertos conocidos (5060 UDP). En el caso de los paquetes de voz el problema puede ser mas complicado porque dependerá de la PBX IP que estemos utilizando para la comunicación. En cualquier caso hay que evitar en la medida de lo posible el abrir todos los puertos TCP y UDP.
2. Problemas con el NAT: Los NAT realizan una “traducción” entre las direcciones IP privadas de la red interna y las direcciones IP públicas de Internet. Este es un gran problema en las comunicaciones a través de SIP y que también sufren otros protocolos utilizados en Voz sobre IP, ya que el NAT impide la entrada de cualquier paquete que no sea una respuesta a una petición previa realizada desde el interior. Además, al estar los teléfonos IP y la propia centralita IP dentro del lado LAN, sus direcciones IP serán direcciones privadas que no tienen ninguna validez al otro lado del NAT, en el lado WAN. 
3. Encriptación de las comunicaciones: En una comunicación SIP es necesario proteger tanto la fase de señalización como la propia fase de transporte a través del protocolo RTP. La primera parte se garantiza mediante el denominado protocolo TLS (Transient Layer Security), que es justo el protocolo utilizado en las comunicaciones mediante https. La segunda parte obliga a utilizar el protocolo SRTP, que significa “secure RTP”. Esto complica de nuevo las comunicaciones SIP ya que el protocolo es muy complejo y a menudo no hay compatibilidad entre diferentes fabricantes de equipos SIP.
4. Complejidad del protocolo SIP: Aunque el diseño original del protocolo SIP era muy sencillo y fácil de implementar, las sucesivas modificaciones y ampliaciones han hecho de SIP un protocolo complejo y difícil de implementar en los equipos SIP, al menos para lograr la interoperabilidad de equipos de diferentes fabricantes. En la actualidad hay más de 30 “documentos de ampliaciones” sobre el estándar SIP, por lo que se puede decir que a nivel práctico, los equipos de diferentes fabricantes “hablan” diferentes dialectos de SIP, con todos los problemas que eso conlleva. Las funciones básicas funcionarán sin problemas en la mayoría de los casos pero las funciones avanzadas a menudo darán problemas entre equipos de diferentes fabricantes.

Alternativas a SIP: Existen otros protocolos y soluciones empleados para las comunicaciones de voz sobre IP. Las características fundamentales de las más conocidas se indican a continuación:

1. H 323: El protocolo H.323 fue estandarizado por la ITU-T para la señalización en las comunicaciones de voz sobre IP. De alguna manera se puede entender que H.323 es una adaptación de los protocolos de señalización de RDSI sobre redes de paquetes, como son las redes IP. A diferencia de SIP, los mensajes no están codificados en forma de texto (como por ejemplo en HTML) sino en forma binaria, al igual que en la RDSI, y por tanto se supone que es más rápido y eficaz que SIP pero más complejo para que terceras partes implementen nuevas funciones sobre él. H.323 fue muy utilizado en la década de 1990 y entre otras aplicaciones, era utilizado por el conocido programa de mensajería Microsoft NetMeeting.  H.323 utiliza también el protocolo RTP para la transmisión de los contenidos y hoy en día puede considerarse un protocolo “obsoleto” en beneficio del protocolo SIP.
2. Inter-Asterisk Exchange Protocol by Asterisk (IAX2): El servidor de VoIP Asterisk soporta varios protocolos para la señalización de voz sobre IP, pero tiene un desarrollo propio denominado Inter-Asterisk Exchange Protocol (IAX) cuya versión más actual es el denominado IAX2. Es un protocolo que inicialmente fue utilizado para comunicar servidores de Asterisk pero que más tarde ha sido implementado en terminales VoIP y en aplicaciones software de desarrolladores independientes del proyecto Asterisk. Una interesante característica de IAX es que envía tanto el flujo de voz como la señalización por el mismo puerto UDP, el puerto 4569. Con esta medida se evitan varios de los problemas que surgen con los firewalls y NAT cuando se utiliza asignación de puertos dinámica, tal y como sucede en SIP y en otros protocolos de VoIP.
3. Skinny Client Control Protocol by Cisco (SCCP): El protocolo SCCP es un desarrollo propio de la empresa CISCO utilizada en sus sistemas CallManager y en los terminales telefónicos asociados. Es un protocolo propietario y la información sobre él es muy escasa aunque sistemas como Asterisk son capaces de entender SCCP a través de módulos de software libre que utilizan sistemas de ingeniería inversa.
4. Asterisk:  En realidad Asterisk no es ningún protocolo de VoIP ya que es un software de servidor de VoIP  y que ha tenido un gran éxito en el mercado de la telefonía IP. Está soportado por la empresa Digium y cuenta con un buen número de tarjetas físicas para convertir un PC que ejecute el software Asterisk en una potente PABX con posibilidad de conectar tanto extensiones analógicas como digitales y también  líneas analógicas y RDSI, tanto en accesos básicos como primarios. Asterisk soporta varios protocolos como SIP, SCCP y el protocolo propio de Asterisk denominado IAX. Estos protocolos pueden ser soportados de forma simultánea, de tal manera que, por ejemplo, un terminal bajo protocolo SIP es capaz de comunicarse con otro terminal bajo protocolo SCCP o IAX a través del server de Asterisk. Otra característica de Asterisk es que es capaz de enrutar todo el tráfico RTP a través del propio server de Asterisk, con lo que se evitan muchos problemas asociados a los Firewalls y a los NAT, aunque esta solución hay que evitarla en llamadas entre terminales VoIP que están en la misma red interna. Asterisk puede servir igualmente de pasarela para comunicar dos dispositivos SIP que utilizan distintos “dialectos ” SIP.

Bueno, y con esto se termina esta breve introducción sobre el protocolo SIP y otros aspectos fundamentales sobre protocolos utilizados en la VoIP.  Esta entrada en el blog tan solo pretende mostrar los fundamentos de los protocolos utilizados en VoIP y en concreto los fundamentos del protocolo que más éxito tiene en la actualidad, el protocolo SIP. Es preciso tener en cuenta que el tema aquí desarrollado es muchísimo más amplio y complejo y que un estudio detallado requiere, no de una breve entrada en un blog, sino de la lectura detallada de extensos documentos de cientos de páginas.

En cualquier caso se hace notar que, al igual que todo el mundo utiliza el teléfono analógico o realiza llamadas a través de un teléfono RDSI sin conocer siquiera la existencia de los complejos protocolos de señalización que están por detrás, con la telefonía sobre IP sucede algo similar: Un técnico en telefonía IP puede instalar y mantener perfectamente una PABX IP con protocolo SIP conociendo simplemente aspectos muy básicos de dicho protocolo. Solo cuando se abordan proyectos de un nivel tecnológico muy superior, como puede ser el desarrollo de aplicaciones que utilizan el protocolo SIP, es cuando serán necesarios conocimientos más profundos de este protocolo SIP y de otros aspectos técnicos igualmente complejos.

Nota: Aunque para la elaboración de esta entrada en el blog se ha consultado información de muchos documentos sobre VoIP existentes en Internet, la mayoría de la información ha sido obtenida de un documento publicado por Henrik Ingo