El Protocolo de Inicio de Sesión (SIP) es un componente fundamental en las comunicaciones de Voz sobre Protocolo de Internet (VoIP), desempeñando un papel crucial en la configuración, el mantenimiento y la finalización de las llamadas de voz y video. A continuación se describirá en detalle cómo funciona el protocolo SIP por dentro.

La importancia de SIP radica en que se trata de un estándar abierto, esto es, no está sujeto a restricciones de propiedad ni a licencias costosas. Esto permite a desarrolladores y proveedores crear soluciones VoIP interoperables que se adaptan a diversas necesidades y presupuestos. Por otro lado, SIP utiliza un lenguaje de descripción basado en texto, lo que lo hace sencillo de implementar y comprender en comparación con protocolos binarios más complejos.

A lo anterior hay que añadirle que SIP está diseñado para manejar un gran volumen de llamadas simultáneas, admite una amplia gama de funciones de comunicación, como llamadas de voz y video, transferencia de llamadas, conferencias o mensajería instantánea.

Por último, hay que destacar que SIP puede interoperar con otros protocolos de VoIP, como H.323, lo que permite la comunicación entre sistemas VoIP dispares. Esto facilita la integración de VoIP con redes telefónicas tradicionales y otras plataformas de comunicación.

Si desea ver cómo se integra SIP dentro del conjunto de protocolos de VoIP, puede consultar este libro online: VoIP. La telefonía de Internet.

Orígenes del protocolo SIP

El IETF creó en 1996 un grupo de trabajo conocido como MMUSIC (Multiparty Multimedia Session Control, ‘Control de sesión multimedia y multiparticipante’) con el objetivo de desarrollar un protocolo que permitiera la comunicación multimedia (audio, vídeo, etc.) entre múltiples usuarios. Ese mismo año propondrían un documento que surgió como resultado de la fusión de dos trabajos: SIP (Session Initiation Protocol, ‘Protocolo de inicio de sesión’), de Mark Handley y E. Schooler, y SCIP (Simple Conference Invitation Protocol, ‘Protocolo simple de invitación a conferencia’) de Henning Schulzrinne.

A pesar de que el documento final adoptara el nombre de SIP, la gran aportación de este nuevo protocolo vendría de Schulzrinne: utilizar la filosofía del protocolo HTTP usado en las páginas Web. Henning Schulzrinne, profesor asociado del Departamento de Ciencia Informática de la Universidad de Columbia y coautor de los protocolos RTP y RTSP (Real Time Streaming Protocol, ‘Protocolo de flujo en tiempo real’), defendió esta idea argumentando que los sistemas de telefonía no se habían cambiado en 100 años y que era una oportunidad única para crear un nuevo sistema de comunicación multimedia desde cero.

Después de varias modificaciones, la versión definitiva de SIP se publicaría en marzo de 1999 como la recomendación RFC2543. Debido al tremendo interés que despertó, el IETF creó nuevos grupos de trabajo, dando paso a la serie de recomendaciones desde la RFC3261 (mayo de 2002) a la RFC3266 (junio de 2002).

La gran ventaja que presenta SIP es que se trata de un protocolo pensado desde Internet para ser utilizado en Internet. Esto quiere decir que SIP aporta lo imprescindible para poder establecer una comunicación (multimedia o de datos) entre dos equipos de Internet, utilizando la misma filosofía que los protocolos de Internet más extendidos (HTTP, SMTP, etc.).

Ventajas de SIP sobre H.323

H.323 es un sistema completo, complejo y unificado, lo que lo convierte en una solución robusta con amplias capacidades de interoperabilidad y escalabilidad para incorporar nuevas funcionalidades. En contraste, SIP es un protocolo más sencillo y adaptable, aunque enfrenta mayores retos en términos de interoperabilidad, pero fue creado desde, por y para Internet.

En las comparaciones con H.323, los defensores de SIP argumentan que se trata de una solución más flexible, simple, fácil de implementar, adaptable a dispositivos inteligentes y más apropiada para ofrecer características avanzadas. Quizás su mayor inconveniente es que no resulta tan compatible con los sistemas telefónicos tradicionales como lo es H.323. En cualquier caso, con el uso de gateways, las redes SIP pueden interconectarse con cualquier otro tipo de red.

El resultado es que SIP está alcanzando unas cuotas de penetración en el mercado de telefonía IP cada vez mayores. De hecho, muchos consideran que SIP reemplazará completamente a H.323. Programas como Skype, Zoom, Google Meet, o Microsoft Teams utilizan el sistema SIP.

SIP puede establecer sesiones entre dos participantes, entre múltiples participantes (donde todos pueden hablar y escuchar) y en modo multidifusión (donde uno habla y los demás escuchan). De la misma forma, las sesiones pueden contener audio, vídeo o datos. Esta última opción permite que se pueda ejecutar cualquier tipo de aplicaciones simultáneamente a la comunicación de voz y vídeo (por ejemplo, para realizar presentaciones, compartir documentos o trabajar en grupo).

Otra curiosidad de SIP es que puede incluir campos opcionales con información específica del usuario. Esta posibilidad permite que los usuarios intercambien información no estándar, lo que hace posible el desarrollo de nuevos servicios. Por ejemplo, se podría incluir un texto en la invitación de la llamada que indicase el asunto: ‘Sobre la reunión de mañana…’. En el caso de rechazar la llamada podría incluirse el motivo: ‘Te llamo dentro de 10 minutos’. Por otro lado, si un usuario no está disponible, podría programar una contestación automática que dijera ‘estaré disponible a partir de las 4 pm’.

La arquitectura SIP

SIP es un protocolo de señalización que ha sido concebido para controlar el establecimiento, modificación y terminación de comunicaciones multimedia (audio, vídeo y datos). Por tanto, una vez establecida la comunicación, el intercambio de información multimedia se lleva a cabo mediante otros protocolos (generalmente RTP/RTCP). En cuanto al nivel de transporte, aunque SIP suele utilizar UDP, también funciona sobre TCP. Por otro lado, recientemente se ha presentado una propuesta para utilizar el protocolo SCTP (Stream Control Transmission Protocol, ‘Protocolo de transporte de control de flujo’, descrito en la recomendación RFC2960 de octubre de 2000).

Desde el punto de vista del nivel de red, SIP se pensó para funcionar sobre IP, no obstante, nada impide que pueda utilizarse sobre cualquier otro protocolo de red: ATM (Asynchronous Transfer Mode, Modo de transferencia asíncrono), FR (Frame Relay) o X25.

La arquitectura de SIP se basa en un modelo cliente-servidor en el que el cliente realiza solicitudes (requests) al servidor, quien le responde (response) para aceptar, rechazar o redirigir dichas solicitudes. Por ejemplo, en una comunicación directa entre terminales, el cliente sería el llamante y el servidor el llamado. El primero le solicita al segundo iniciar una sesión.

Además de los terminales de usuario, que pueden ser tanto clientes como servidores, la arquitectura SIP considera la existencia de otro tipo de servidores para poder crear redes multimedia más complejas.

La comunicación entre clientes y servidores se realiza mediante el envío de mensajes en modo texto, con una sintaxis muy similar a la de los mensajes HTTP. Esto quiere decir que los mensajes están compuestos por textos que son perfectamente legibles, lo que facilita las labores de desarrollo, así como la compatibilidad con las aplicaciones HTTP, que también se basan en textos legibles.

Componentes del protocolo SIP

Desde el punto de vista del equipamiento, la arquitectura SIP supone la existencia de dos tipos de equipos: terminales y servidores de red. Los terminales son los equipos finales que utilizan los usuarios, mientras que los servidores de red son equipos intermedios que aportan funcionalidad a las redes SIP.

Los equipos terminales disponen de dos componentes fundamentales:

Agente de usuario cliente o UAC (User Agent Client). Se trata de la aplicación que permite que el terminal pueda realizar o iniciar una llamada. El UAC se utiliza para enviar solicitudes SIP.
Agente de usuario servidor o UAS (User Agent Server). Se trata de la aplicación que permite que el terminal pueda recibir o responder a una llamada realizada por el UAC. El UAS recibe solicitudes SIP y devuelve las respuestas correspondientes en nombre del usuario. Estas respuestas pueden ser de aceptación, rechazo o redirección de la solicitud.

Los agentes de usuario le dan una funcionalidad completa al terminal, de forma que pueden utilizarse sin la intervención de los servidores de red. Por otro lado, podría haber terminales que contengan sólo uno de los agentes de usuario. En este caso, el terminal se utilizaría exclusivamente para escuchar o para transmitir.

En cuanto a los servidores de red, existen tres tipos:

Servidor proxy (proxy server). Se trata de un equipo que recibe solicitudes del cliente, las analiza y decide el servidor al que debe reenviarlas. Si es necesario, el proxy puede modificar el mensaje de solicitud antes de reenviarlo. Para el siguiente servidor el mensaje procede del proxy. Una solicitud puede atravesar distintos servidores proxy antes de alcanzar su destino. En este caso, la respuesta atravesaría todo el camino inverso. Como el proxy maneja solicitudes y respuestas, necesita disponer, tanto de la funcionalidad cliente, como de la de servidor. Por otro lado, los servidores proxy pueden mantener un registro de todas las llamadas en curso o no (a estos modos se los conoce como statefull y stateless respectivamente). En el caso de que el proxy no mantenga un registro de la llamada se limitará a reenviar la solicitud y listo. El registro de llamadas es necesario para poder ofrecer determinados servicios de valor añadido o, incluso, para determinadas aplicaciones de gestión.
Servidor de redireccionamiento (Redirect Server). Estos servidores no reenvían los mensajes de solicitud, sino que le responde al cliente con la dirección, o direcciones, del servidor al que le tienen que enviar la solicitud. En este caso, es el cliente el que contacta directamente con el nuevo servidor. El servidor de redireccionamiento no contacta con otros servidores ni acepta llamadas (no tiene la funcionalidad de agente de usuario servidor).
Servidor de registro (Registrar Server). Este servidor mantiene un registro de la dirección SIP de un usuario y de su dirección IP correspondiente. Esto permite tener localizado a un usuario en todo momento. Por ejemplo, si un usuario dispone de distintos dispositivos SIP (ordenador de la oficina, PDA, ordenador de casa, etc.), cuando entra (log-in) en cualquiera de ellos, el dispositivo le envía un mensaje al servidor de registro avisándole de su nueva dirección IP, con lo que el servidor ya sabe dónde tiene que reenviar las llamadas con destino a dicho usuario. A este servidor se lo conoce también como servidor de localización (location server)

Aunque los servidores de red podrían estar físicamente localizados en equipos distintos, suele ser normal que un mismo equipo tenga la funcionalidad de varios tipos de servidores, especialmente la combinación del servidor de registro con cualquiera de los anteriores.

URI. Las direcciones SIP

SIP permite la interconexión de equipos, tanto de una red IP como de otro tipo de redes a través de gateways. Para que desde un equipo se pueda establecer una comunicación con otro, es necesario poder identificarlo de alguna forma. La red telefónica cuenta con un sistema de numeración internacional, Internet cuenta con el sistema de números IP y de nombres de dominio. El reto de SIP es establecer un sistema de identificación que sea compatible con distintas redes y que dé respuesta a todas las necesidades propias de un gateway. La solución es URI (Uniform Resource Identifier, ‘Identificador uniforme de recursos’).

El formato de URI está definido en la recomendación RFC2396 y se basa en la estructura de direccionamiento empleada en Internet y conocida como URL (Uniform Resource Locators, ‘Localizador universal de recursos’). De hecho, las direcciones URI tienen un formato similar al de una dirección de correo electrónico.

El formato general de una dirección URI es el siguiente:

sip:12Husuario@dominio;parámetro=valor

Este tipo de direccionamiento permite, por ejemplo, que se utilice un número telefónico tradicional en el campo usuario, identificándose en el campo dominio la dirección del gateway que interconecta con la red telefónica tradicional donde se encuentra dicho número. De la misma forma, el dominio de las direcciones URI podría ser también un número IP.

Por cierto, recuerde que el formato URL de una dirección de correo electrónico es mailto:usuario@dominio. Esto nos deja ver la similitud de ambos formatos.

Los mensajes SIP

Los mensajes del protocolo de señalización SIP son de dos tipos: solicitudes (requests) y respuestas (responses). Los clientes envían mensajes de solicitudes a los servidores; quienes responden a los clientes con mensajes de respuestas. El formato de los mensajes de solicitud y de respuesta es el mismo. Ambos disponen de una cabecera formada por distintos campos y de un cuerpo del mensaje.

Los mensajes se basan en el envío de textos utilizando la tabla de caracteres ISO 10646 y conocido como conjunto universal de caracteres (UCS, Universal Character Set). Esta tabla, al igual que la tabla ASCII, define el conjunto de ceros y unos que debe representar a cada carácter. No obstante, la ventaja de ISO 10646 frente a ASCII (más conocido en el mundo del PC) es que recoge todos los caracteres internacionales, incluidos los de caligrafías asiáticas.

Como los mensajes de SIP están formados por textos, esto quiere decir que si una persona viese el contenido de uno de estos mensajes, podría interpretarlo fácilmente (al igual que ocurre con el formato HTTP).

El formato general de los mensajes (de solicitud y respuesta) está definido en la recomendación RFC822, y se compone de:

Una línea de inicio (start-line). Esta línea define el tipo de mensaje de que se trata. Existen dos tipos: línea de solicitud, utilizada por los mensajes de solicitud, y línea de respuesta, utilizada por los mensajes de respuesta.
Una cabecera formada por uno o más campos de cabecera (headers). La cabecera se utiliza para incluir información adicional relativa a la solicitud o la respuesta. Por ejemplo, se incluye desde el remitente o el destinatario, hasta un texto indicando el motivo de la llamada.
Una línea en blanco para indicar el final de la cabecera.
El cuerpo del mensaje (message-body). SIP no define la estructura del cuerpo del mensaje ni se ocupa de su contenido. No obstante, normalmente, el cuerpo del mensaje se utiliza para describir el tipo de sesión que se va a establecer, versión del codec a utilizar, etc. Lo más habitual es utilizar la estructura definida por el protocolo SDP (Session Description Protocol, ‘Protocolo de descripción de sesión’), aunque podría utilizarse cualquier otra. De hecho, el cuerpo del mensaje podría contener múltiples partes, cada una de ellas codificada con un protocolo distinto. Esta versatilidad hace posible utilizar SIP, por ejemplo, para transportar mensajes SS7 en formato binario, permitiendo, de esta forma, la interconexión con la red telefónica.

La línea de solicitud

En el caso de los mensajes de solicitud, la línea de inicio recibe el nombre de línea de solicitud (request-line) y está formada por los siguientes componentes: una palabra que indica el tipo de solicitud de que se trata (método), dirección URI del servidor al que se dirige la solicitud e indicación de la versión del protocolo SIP utilizado. Estos tres componentes estarán separados por un espacio y terminarán con un carácter CRLF (un carácter particular de UCS que se conoce como Carriage Return and Line Feed, ‘Retorno de carro y cambio de línea’).

La sintaxis sería la siguiente:

Método URI Versión-sipCRLF

A los tipos de solicitudes se los conoce como métodos (methods) y están identificados por una palabra. En la versión 2.0 de SIP se incluyen seis tipos de solicitudes o métodos:

INVITE (invitar). Este mensaje se utiliza para invitar a participar en una sesión (una llamada). En el cuerpo del mensaje se incluye el resto de parámetros necesarios: por ejemplo, el asunto de la llamada o el tipo de formato multimedia que puede utilizar el terminal llamante. Por su parte, el terminal llamado incluirá en el cuerpo del mensaje de su respuesta de aceptación los formatos multimedia que acepta.
ACK (aceptación). Esta solicitud se utiliza para que el cliente (llamante) pueda confirmarle al servidor (llamado) que ha recibido su respuesta final de aceptación de participación en la sesión (llamada). Este método se utiliza exclusivamente con solicitudes INVITE, y no con otro tipo de solicitudes.
OPTIONS (opciones). Se utiliza para preguntarle a un servidor por sus capacidades (los formatos multimedia que acepta, etc.). Se utiliza antes de iniciar la llamada para averiguar si admite determinadas características.
BYE (adiós). Este mensaje se utiliza para terminar una sesión. Generalmente, se envía cuando cuelga el usuario.
CANCEL (cancelar). Se utiliza para anular una solicitud para la que todavía no se ha recibido respuesta.
REGISTER (registrar). Se utiliza para que un cliente pueda registrar su localización actual en un servidor SIP. El cliente puede registrarse en un servidor del que conoce su dirección o en todos los servidores SIP a través de la dirección multicast 224.0.1.175.

El siguiente podría ser un ejemplo de una línea de solicitud:

INVITE sip:coco@mumse.com SIP/2.0

Algunas extensiones de SIP definen métodos adicionales como: INFO, REFER o UPDATE. Por ejemplo, el método INFO, definido en RFC2976, se utiliza para transferir información durante el curso de una sesión (durante la llamada). Este método podría utilizarse, por ejemplo, para transmitir el coste de la llamada en curso, para retransmitir los tonos multifrecuencia marcados en el terminal o para informarle a un usuario prepago de que su saldo está a punto de acabarse.

La línea de respuesta

En el caso de tratarse de un mensaje de respuesta, éste informará del estado en el que se encuentra el servidor o si la solicitud se ha aceptado o rechazado. Las líneas de inicio de los mensajes de respuesta se conocen como líneas de estado o línea de respuesta.

El tipo de respuesta se transmite con un código numérico conocido como código de estado (status code). La línea de estado está formada por tres componentes: versión del protocolo SIP, el código de estado y un texto con una breve explicación del código de estado incluido en el mensaje. Este texto ayuda a que una persona pueda interpretar directamente el mensaje de respuesta.

Al igual que ocurre con la línea de solicitud, los tres componentes de la línea de respuesta están separados por un espacio y termina con un carácter CRLF.

La sintaxis sería la siguiente:

Versión-sip Código TextoCRLF

Los códigos de estado tienen tres dígitos, donde el primero define la clase de respuesta y los otros dos el mensaje concreto dentro de la clase. Actualmente existen seis clases diferentes de mensajes de respuestas:

1xx. De información (Informational). Indica que se ha recibido la solicitud y que se está procesando. Por ejemplo, el mensaje 180 indica que está haciendo sonar el timbre del usuario.
2xx. De aceptación (Successful). Indica que se ha recibido la solicitud y que todo está correcto para ejecutarla.
3xx. Redirección (Redirection). Indica que el usuario llamado no está disponible en la dirección utilizada en la solicitud y que será redireccionada a la nueva dirección que se adjunta.
4xx. Fallo en la solicitud (Request Failure). Indica que el mensaje de solicitud no es del todo correcto: existe algún error de sintaxis, no se está autorizado, etc.
5xx. Fallo en el servidor (Server Failure). Indica que, aunque el mensaje de solicitud es válido, el servidor tiene algún problema para aceptarlo: servicio no disponible, saturación, error interno del servidor, etc.
6xx. Fallo general (Global Failure). Indica que no se puede dar respuesta a la solicitud por algún tipo de fallo general.

Salvo las respuestas de información (1xx), el resto se consideran respuestas finales que dan por terminada la transacción SIP. Las respuestas 1xx son provisionales y no dan por terminada la transacción SIP.

En la tabla adjunta se proponen ejemplos de una línea de estado.

La cabecera de SIP

La cabecera de los mensajes está formada por campos, y tienen un formato similar al de las cabeceras de HTTP. Algunos de estos campos son utilizados en todos los tipos de mensajes, mientras que otros son específicos de un tipo de mensaje particular.

Por otro lado, existen campos de cabecera que pueden ser modificados o añadidos por los servidores proxy que intervienen en la comunicación, mientras que otros van dirigidos directamente a ser interpretados por el agente de usuario. A los primeros se los conoce como hop-by-hop (salto a salto) y a los segundos como end-to-end (extremo a extremo). Aunque el orden en el que aparecen los campos en la cabecera del mensaje es indiferente, los campos hop-by-hop deben aparecer antes que los campos end-to-end.

Inicialmente, la recomendación RFC2543 incluía 37 campos de cabecera, no obstante, en la actualidad ya hay definidos 46. Estos campos están divididos en cuatro grupos diferentes:

Campos generales (general headers). Se utilizan, tanto en los mensajes de solicitudes como en los de respuesta, para incluir información básica necesaria para la gestión de los mensajes. Estos campos son: Call-ID, Contact, Cseq, Date, Encryption, From, Organization, Retry-After, Subject, Supported, Timestamp, To, User Agent y Via.
Campos de entidad (entity headers). Definen información adicional relacionada con el cuerpo del mensaje (SDP) o, si no hubiera cuerpo del mensaje, sobre los recursos identificados en la solicitud. El propósito de estos campos es indicar el tipo y formato de la información incluida en el cuerpo del mensaje. Son estos: Allow, Content-Encoding, Content-Length, Content-Type, Content-Disposition, Expires y MIME-Version.
Campos de solicitud (request headers). Los utilizan los clientes para incluir información adicional relacionada con la solicitud o con el propio cliente. Son los siguientes: Accept, Accept-Encoding, Accept-Language, Accept-Contact, Authorization, Hide, In-Reply-To, Max-Forwards, Priority, Proxy-Authorization, Proxy-Require, Record-Route, Reject-Contact, Request-Disposition, Require, Response-Key, Route, Rack y Session-Expires.
Campos de respuesta (response headers). Los utilizan los servidores para incluir información adicional relacionada con la respuesta. Estos son: Proxy-Authenticate, Server, Unsupported, Warning, WWW-Authenticate y Rseq.

Si se está interesado en la definición de todos los campos, se puede recurrir a la recomendación RFC2543, no obstante, para hacernos una idea de su utilización será suficiente con ver el significado de alguno de ellos:

Call-ID (Identificación de la llamada). Es un código que identifica cada llamada de forma unívoca, permitiendo, por ejemplo, hacer corresponder una respuesta con su solicitud, detectar duplicados de solicitudes INVITE o cambiar dinámicamente los parámetros de una llamada.
Cseq (Identificación de la solicitud). Identifica cada solicitud. La respuesta a una solicitud incorpora el mismo Cseq.
From (Desde). Aparece en todos los mensajes de solicitud y de respuesta para identificar el origen de la solicitud (terminal llamante).
To (Para). Aparece en todos los mensajes de solicitud y de respuesta para identificar al destinatario de la solicitud (terminal llamado).
Via. Registra la ruta que sigue la solicitud. Por tanto, cada proxy por el que pasa la solicitud añade un campo Via.
Content-Length (Longitud del contenido). Longitud del cuerpo del mensaje en octetos.
Content-Type (Tipo de contenido). Indica el tipo de contenido incluido en el cuerpo del mensaje (normalmente será SDP, valor application/sdp).
Content-Disposition (Disposición del contenido). Indica cómo debe interpretarse el cuerpo del mensaje. Algunos de los valores son: session, para indicar que se trata de una descripción de las características de una sesión (SDP), icon, para indicar que el cuerpo incluye una foto del llamante, render, para indicar que se trata de un texto para ser mostrado a la otra parte, o alert, para indicar que se trata de un audioclip o timbre personalizado.
Subject (Asunto). Se trata de un texto que indica la naturaleza de la llamada.

El siguiente es un ejemplo de la cabecera de un mensaje:

INVITE sip:coco@mumse.com SIP/2.0
Via:SIP/2.0/UDP Cani.com
From: ana<sip:ana@delhi.mumse.com>
To: Marcos 14Hcoco@mumse.com
Call-ID:123456789@cani.com
Content-Type:application/sdp
Cseq:1 INVITE
Content-Length: 232

El cuerpo del mensaje. SDP

Los mensajes SIP no están obligados a incluir un cuerpo, sin embargo, cuando lo hacen, puede tratarse de información dirigida a cualquier aplicación del usuario o información de señalización. El contenido del cuerpo del mensaje no es analizado por los equipos intermedios de la red, sino que sólo es de interés para los equipos terminales (agentes de usuario).

Campos de cabecera a incluir en cada solicitud

Campos de cabecera a incluir en cada respuesta

Como el cuerpo del mensaje puede utilizarse para distintas finalidades (algunas de ellas muy particulares), SIP no define su estructura, pudiéndose utilizar cualquier mecanismo que se estime oportuno. No obstante, cuando SIP utiliza el cuerpo del mensaje para el intercambio de información de señalización, suele utilizar el protocolo SDP (Session Description Protocol, ‘Protocolo de descripción de la sesión’).

La información de señalización que incluye SIP en el cuerpo del mensaje se utiliza principalmente para acordar las características de la comunicación multimedia de acuerdo a las propiedades o preferencias configuradas en los equipos participantes. El cuerpo del mensaje viene a ser a SIP lo que el protocolo H.245 es a las comunicaciones H.323.

SDP no es un protocolo diseñado para SIP, sino que se puede utilizar en distintos entornos. El objeto de SDP es describir las características de una sesión multimedia, incluido el anuncio, invitación u otras formas de inicio de la sesión. No obstante, SIP sólo utiliza parte de las características de SDP. Por ejemplo, aunque SDP permite el intercambio de parámetros de reuniones periódicas con múltiples participantes y de duración limitada, esto no se utiliza con SIP, donde las comunicaciones suelen ser espontáneas y de duración ilimitada.

Aunque SDP se describió por primera vez en la RFC2327 (abril de 1998), desde entonces se han sugerido varias mejoras que están recogidas en distintas recomendaciones. Por otro lado, la recomendación RFC3264 describe cómo se utiliza SDP y SIP de forma conjunta.

SDP, al igual que SIP, intercambia información en modo texto utilizando la tabla de caracteres ISO10646 (codificación UTF-8, RFC2044) .

La forma que tiene SIP de utilizar SDP consiste en que el terminal que origina la llamada incluye una descripción de todas sus características (dirección, puerto y formatos multimedia que acepta por orden de preferencia). El destinatario le responde con sus características y con una aceptación o rechazo de cada uno de los formatos propuestos. El resultado es un acuerdo entre las partes de los parámetros de la comunicación.

SDP distingue entre los parámetros que le afectan a la sesión y aquellos que le afectan a un medio particular (por ejemplo, audio, vídeo, datos, etc.). Entre los primeros se encuentra el nombre de la sesión o la identificación del remitente, mientras que entre los segundos se encuentra el tipo de medio, protocolo de transporte utilizado o el número de puerto.

SDP tiene definido todo un conjunto de campos que recogen todos los parámetros que se necesitan intercambiar. Un mensaje SDP se compone de líneas de texto donde cada línea representa un campo. La línea comienza por una letra, que identifica al campo, seguido del signo igual (=) y de su valor correspondiente. No debe haber ningún espacio en blanco ni antes ni después del signo igual. La sintaxis sería la siguiente:

campo=valor

Para definir algunos campos es necesario incluir más de un valor (subcampos). En estos casos, se incluirán los valores uno a continuación de otro, en un orden prefijado, y separados por un espacio.

Los campos que tienen que ver con la sesión se incluyen antes que los que tienen que ver con un medio. Por otro lado, existen campos que deben incluirse obligatoriamente (v, o, s, t, y m), mientras que otros son opcionales. Por último, algunos campos pueden utilizarse tanto a nivel de sesión como a nivel del medio.

SDP define que el orden en el que deben aparecer los campos es el siguiente:

Para los campos de nivel de sesión: v, o, s, i, u, e, p, c, b, t, r, z, k y a
Para los campos de nivel del medio: m, i, c, b, k, a

Por cierto, algunos campos de SDP no tienen sentido dentro de SIP (por ejemplo, s, i, u, t, r, z). En estos casos, o bien no se incluyen, o bien, de ser obligatorios, tomarán un valor sin aportar información.

Los campos de SDP son los siguientes:

v (version). Versión del protocolo.
o (origin, origen). Identifica al remitente y a la sesión. Tiene seis subcampos: nombre de usuario del remitente (suele tomarse el nombre de usuario configurado en el ordenador del remitente, aunque si no existe se incluye un guión -), identificador de sesión (identificador único creado por el ordenador del remitente), versión de la sesión, tipo de red (texto indicando el tipo de red, en el caso de Internet se utiliza IN), tipo de dirección (por ejemplo IP4 o IP6 para indicar la versión 4 ó 6 del protocolo IP) y dirección (dirección de la máquina del remitente, puede indicarse como IP o como dominio).
s (session name, nombre de la sesión). Se trata de un texto descriptivo que suele mostrarse a los participantes de la sesión. Este texto es especialmente interesante en las sesiones multicast. En el caso de SIP, donde las sesiones suelen ser unicast con sólo dos participantes, este texto no tiene sentido, por lo que suele utilizarse un espacio en blanco.
t (time, hora). Facilita la hora predefinida de comienzo y terminación de la sesión. En las sesiones entre dos participantes con duración indefinida (SIP) el valor de este campo será t=0 0.
m (media type, tipo de medio). Tiene cuatro subcampos: tipo de medio (audio, vídeo, aplicación, datos o control), puerto (número de puerto utilizado en destino), protocolo de transporte utilizado (RTP) y formatos multimedia aceptados (se incluye una lista de formatos multimedia por orden de preferencia). Los números de puerto dependen del tipo de conexión y del protocolo de transporte utilizado. Como en VoIP se utiliza el protocolo RTP sobre UDP, el número de puerto puede ser cualquier valor entre 1024 y 65535. Por ejemplo, m=audio 45678 RTP/AVP 15 3 0 indica que se desea recibir voz (audio) en el puerto 45.678 sobre RTP con codec del tipo 15 (G.728), 3 (GSM) o 0 (G.711 ley μ).
i (session information, información de sesión). Se trata de un texto que describe el asunto de la sesión. Este campo ofrece más detalles que el nombre de la sesión. No obstante, como la cabecera de SIP ya incluye el campo asunto (subject), generalmente, no se utiliza este campo.
u (URI) Se trata de una dirección URI donde obtener más información sobre la sesión. Esta información suele ser especialmente útil en multiconferencias acordadas en las agendas de los participantes. Como las sesiones SIP suelen establecerse sin agenda previa, este campo deja de tener utilidad en este caso.
e (email). Dirección de correo electrónico de la persona responsable de la sesión.
p (phone, teléfono). Teléfono de la persona responsable de la sesión.
c (connection, conexión). Tiene tres subcampos: tipo de red, tipo de dirección y dirección de conexión. Tienen el mismo significado que los subcampos de o (origen) pero referido al destinatario.
b (bandwidth, ancho de banda). Especifica el ancho de banda necesario en kilobits por segundo.
r (regularly, periódico). Este campo se utiliza en las multiconferencias que se celebran de forma periódica para especificar cada cuanto tiempo y cuantas veces debe celebrarse esta conferencia. Este valor no tiene sentido con SIP.
z (timezone, zona horaria). Indica la zona horaria utilizada. Este campo tiene sentido en las sesiones periódicas, por lo que no suele utilizarse con SIP.
k (encryption, cifrado). Facilita una clave de cifrado o especifica el mecanismo por el que puede ser obtenida la clave para cifrar y descifrar la información multimedia.
a (additional attributes, atributos adicionales). Se utiliza para describir atributos adicionales que sean de aplicación a la sesión o a un medio individual.

Más información sobre VoIP

En este artículo se ha abordado el funcionamiento del protocolo SIP de inicio de sesión en las comunicaciones de VoIP. El funcionamiento de internet en general y de la voz sobre IP en particular son ampliamente tratados en este blog en múltiples artículos. Por favor, utilice el buscador de contenidos que tenemos en la cabecera.

Por otro lado, estos son algunos otros artículos que pueden ser de interés:

REF: VoIP PG132

Protocolo SIP de VOIP