Protocolo de iniciación de sesión

Protocolo de inicio de sesión (en inglés: Session Initiation Protocol o SIP) es un protocolo desarrollado por el grupo de trabajo MMUSIC (Multiparty Multimedia Session Control) del IETF con la intención de ser el estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos en línea y realidad virtual.

La sintaxis de sus operaciones se asemeja a las de HTTP y SMTP, los protocolos utilizados en los servicios de páginas Web y de distribución de mensajes de correo electrónico respectivamente. Esta similitud es natural ya que SIP fue diseñado para que la telefonía se vuelva un servicio más en Internet.

En noviembre del año 2000, SIP fue aceptado como el protocolo de señalización de 3GPP y elemento permanente de la arquitectura IMS (IP Multimedia Subsystem). SIP es uno de los protocolos de señalización para voz sobre IP, otros, por ejemplo, son H.323 e IAX2.

Historia del protocolo SIP

El 22 de febrero de 1996, Mark Handley y Eve Schooler presentaron al IETF un borrador del Session Invitation Protocol conocido ahora como SIPv1. El mismo estaba basado en trabajos anteriores de Thierry Turletti (INRIA Videoconferencing System o IVS) y de Eve Schooler (Multimedia Conference Control o MMCC). Su principal fortaleza, heredada por la versión actual de SIP, era el concepto de registro, por el cual un usuario informaba a la red dónde (en qué host de Internet) podía recibir invitaciones a conferencias. Esta característica permitía la movilidad del usuario.^[1]

Ese mismo día Henning Schulzrinne presentó un borrador del Simple Conference Invitation Protocol (SCIP), que estaba basado en el HTTP (Hypertext Transport Protocol). Usaba TCP (Transmission Control Protocol) como protocolo de transporte. Como identificadores de los usuarios utilizaba direcciones de correo electrónico para permitir el uso de una misma dirección para recibir correos electrónicos e invitaciones a conferencias multimedia. No utilizaba al SDP para la descripción de los contenidos sino que creaba un mecanismo propio.^[1]

El IETF decidió combinar ambos en un único protocolo denominado Session Initiation Protocol, (es decir cambiando el significado de la inicial I en el acrónimo "SIP") y su número de versión fue el dos, dando origen al SIPv2. En diciembre de 1996 los tres autores (Schulzrinne, Handley y Schooler), presentaron el borrador del SIPv2. El mismo luego de ser discutido en el grupo de trabajo MMUSIC (Multiparty Multimedia Session Control) del IETF alcanzó el grado de "proposed standard" en la RFC 2543 publicada en febrero de 1999.^[1]

En septiembre de 1999 se creó el grupo de trabajo SIP en el IETF que continuó con el desarrollo del protocolo y en junio de 2002 se publicó la RFC 3261 que reemplazó a la anterior introduciendo modificaciones propuestas durante el trabajo del grupo SIP. Los autores de esta última RFC, hoy vigente son: Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Allan Johnston, Jon Peterson, Robert Sparks, Mark Handley y Eve Schooler.^[1]

Diseño del protocolo

El protocolo SIP fue diseñado por el IETF con el concepto de "caja de herramientas",^[1] es decir, el protocolo SIP se vale de las funciones aportadas por otros protocolos, que da por hechas y no vuelve a desarrollar. Debido a este concepto, SIP funciona en colaboración con otros muchos protocolos. El protocolo SIP se concentra en el establecimiento, modificación y terminación de las sesiones, y se complementa entre otros con el SDP, que describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecs se usarán durante la comunicación. Es un protocolo de señalización.^[2] Se complementa con el RTP (Real-time Transport Protocol), portador del contenido de voz y vídeo que intercambian los participantes en una sesión establecida por SIP.

Otro concepto importante en su diseño es el de extensibilidad. Esto significa que las funciones básicas del protocolo, definidas en la RFC 3261, pueden ser extendidas mediante otras RFC (Requests for Comments) dotando al protocolo de funciones más potentes.

Las funciones básicas del protocolo incluyen:

Determinar la ubicación de los usuarios, aportando movilidad.
Establecer, modificar y terminar sesiones multipartitas entre usuarios.

El protocolo SIP adopta el modelo cliente-servidor y es transaccional. El cliente realiza peticiones (requests) que el servidor atiende y genera una o más respuestas (dependiendo de la naturaleza, método de la petición). Por ejemplo para iniciar una sesión el cliente realiza una petición con el método INVITE en donde indica con qué usuario (o recurso) quiere establecer la sesión. El servidor responde ya sea rechazando o aceptado esa petición en una serie de respuestas. Las respuestas llevan un código de estado que brindan información acerca de si las peticiones fueron resueltas con éxito o si se produjo un error. La petición inicial y todas sus respuestas constituyen una transacción.

Los servidores, por defecto, utilizan el puerto 5060 en TCP (Transmission Control Protocol) y UDP (User Datagram Protocol) para recibir las peticiones de los clientes SIP. En caso de mandar la señalización encriptada, SIP usa el puerto 5061.

SIP es similar a HTTP y comparte con él algunos de sus principios de diseño: es legible por humanos y sigue una estructura de petición-respuesta. Además, comparte muchos códigos de estado de HTTP, como el familiar '404 no encontrado' (404 not found). SIP no se limita a comunicaciones de voz y pueden mediar en cualquier tipo de sesión comunicativa desde voz hasta vídeo o futuras aplicaciones todavía sin realizar.

Aunque existen muchos otros protocolos de señalización para VoIP, SIP se caracteriza porque sus promotores tienen sus raíces en la comunidad IP y no en la industria de las telecomunicaciones.

Funcionamiento del protocolo

El protocolo SIP permite el establecimiento de sesiones multimedia entre dos o más usuarios. Para hacerlo se vale del intercambio de mensajes entre las partes que quieren comunicarse.

SIP registro del agente de usuario en SIP Registrar con autenticación por login

El establecimiento de una conexión con el B2BUA

Agentes de usuario

Los usuarios, que pueden ser seres humanos o aplicaciones de software,^{[nota 1]} utilizan para establecer sesiones lo que el protocolo SIP denomina "Agentes de usuario". Estos no son más que los puntos extremos del protocolo, es decir son los que emiten y consumen los mensajes del protocolo SIP. Un videoteléfono, un teléfono, un cliente de software (softphone) y cualquier otro dispositivo similar es para el protocolo SIP un agente de usuario. El protocolo SIP no se ocupa de la interfaz de estos dispositivos con el usuario final, sólo se interesa por los mensajes que estos generan y cómo se comportan al recibir determinados mensajes.

Los agentes de usuario se comportan como clientes (UAC: User Agent Clients) y como servidores (UAS: User Agent Servers). Son UAC cuando realizan una petición y son UAS cuando la reciben. Por esto los agentes de usuario deben implementar un UAC y un UAS.

Además de los agentes de usuario existen otras entidades que intervienen en el protocolo, estos son los servidores de registro o registrar, los proxy y los redirectores. A continuación se describe su finalidad.

Servidores de registro o Registrar

El protocolo SIP permite establecer la ubicación física de un usuario determinado, esto es, en qué punto de la red está conectado. Para ello se vale del mecanismo de registro. Este mecanismo funciona como sigue:

Cada usuario tiene una dirección lógica que es invariable respecto de la ubicación física del usuario. Una dirección lógica del protocolo SIP es de la forma usuario@dominio es decir tiene la misma forma que una dirección de correo electrónico. La dirección física (denominada "dirección de contacto") es dependiente del lugar en donde el usuario está conectado (de su dirección IP). Cuando un usuario inicializa su terminal (por ejemplo conectando su teléfono o abriendo su software de telefonía SIP) el agente de usuario SIP que reside en dicho terminal envía una petición con el método REGISTER a un Servidor de Registro (Registrar en inglés), informando a qué dirección física debe asociarse la dirección lógica del usuario. El servidor de registro realiza entonces dicha asociación (denominada binding). Esta asociación tiene un período de vigencia y si no es renovada, caduca. También puede terminarse mediante un desregistro. La forma en que dicha asociación es almacenada en la red no es determinada por el protocolo SIP, pero es vital que los elementos de la red SIP accedan a dicha información.

Servidores proxy y de redirección

Para encaminar un mensaje entre un agente de usuario cliente y un agente de usuario servidor normalmente se recurre a los servidores.^[3] Estos servidores pueden actuar de dos maneras:

Como Proxy, encaminando el mensaje hacia destino,
Como Redirector (Redirect) generando una respuesta que indica al originante la dirección del destino o de otro servidor que lo acerque al destino.

La principal diferencia es que el servidor proxy queda formando parte del camino entre el UAC y el (o los) UAS, mientras que el servidor de redirección una vez que indica al UAC cómo encaminar el mensaje ya no interviene más.

Un mismo servidor puede actuar como Redirector o como Proxy dependiendo de la situación.

Servidor de localización

Un servidor de localización, simplemente da información acerca de donde puede estar el cliente al que se quiere llamar para así poder localizarlo.

Casos típicos de servidores

Un conjunto de usuarios que pertenecen a una compañía o proveedor de servicios de comunicaciones, conforman un dominio. Este dominio, que se indica en una dirección SIP después del carácter "@" es normalmente atendido por un servidor. Este servidor recibe las peticiones hacia sus usuarios. Este servidor será el encargado de determinar la dirección física del usuario llamado. Un servidor que recibe las peticiones destinadas a un dominio específico es denominado servidor entrante (Inbound Server).

Es habitual también, que exista un servidor que reciba las peticiones originadas por los usuarios de un dominio hacia otros dominios. Este recibe el nombre de Servidor Saliente (Outbound Server).

Un agente de usuario normalmente encamina todos sus pedidos hacia un servidor de su propio dominio. Es este quien determina (por sus propios medios o valiéndose de otros servidores) las ubicaciones de los usuarios que son llamados por el agente de usuario en cuestión.

Formato de los mensajes

Los mensajes que se intercambian en el protocolo SIP pueden ser peticiones o respuestas.

Las peticiones tienen una línea de petición, una serie de encabezados y un cuerpo.

Las respuestas tienen una línea de respuesta, una serie de encabezados y un cuerpo.

En la línea de petición se indica el propósito de la petición y el destinatario de la petición.

Las peticiones tienen distintas funciones. El propósito de una petición está determinado por lo que se denomina el Método (Method) de dicha petición, que no es más que un identificador del propósito de la petición. En la RFC 3261 se definen los métodos básicos del protocolo. Existen otros métodos definidos en extensiones al protocolo SIP.

En la línea de respuesta se indica el código de estado de la respuesta, que es un número que indica el resultado del procesamiento de la petición.

Los encabezados de peticiones y respuestas se utilizan para diversas funciones del protocolo relacionadas con el encaminamiento de los mensajes, autenticación de los usuarios, entre otras. La extensibilidad del protocolo permite crear nuevos encabezados para los mensajes agregando de esta manera funcionalidad.

El cuerpo de los mensajes es opcional y se utiliza entre otras cosas para transportar las descripciones de las sesiones que se quieren establecer, utilizando la sintaxis del protocolo SDP.

Flujo de establecimiento de una sesión

El flujo habitual del establecimiento de una sesión mediante el protocolo SIP es el siguiente (en este ejemplo todos los servidores actúan como proxy):

Un usuario ingresa la dirección lógica de la persona con la que quiere comunicarse, puede indicar al terminal también la característica de la sesión que quiere establecer (voz, voz y video, etc.), o estas pueden estar implícitas por el tipo de terminal del que se trate. El agente de usuario SIP que reside en el terminal, actuando como UAC envía la petición (en este caso con el método INVITE) al servidor que tiene configurado. Este servidor se vale del sistema DNS para determinar la dirección del servidor SIP del dominio del destinatario. El dominio lo conoce pues es parte de la dirección lógica del destinatario. Una vez obtenida la dirección del servidor del dominio destino, encamina hacia allí la petición. El servidor del dominio destino establece que la petición es para un usuario de su dominio y entonces se vale de la información de registro de dicho usuario para establecer su ubicación física. Si la encuentra, entonces encamina la petición hacia dicha dirección. El agente de usuario destino si se encuentra desocupado comenzará a alertar al usuario destino y envía una respuesta hacia el usuario origen con un código de estado que indica esta situación (180 en este caso). La respuesta sigue el camino inverso hacia el usuario origen. Cuando el usuario destino finalmente acepta la invitación, se genera una respuesta con un código de estado (el 200) que indica que la petición fue aceptada. La recepción de la respuesta final es confirmada por el UAC origen mediante una petición con el método ACK (de Acknowledgement), esta petición no genera respuestas y completa la transacción de establecimiento de la sesión.

Normalmente la petición con el método INVITE lleva un cuerpo donde viaja una descripción de la sesión que quiere establecer, esta descripción es realizada con el protocolo SDP.^{[nota 2]} En ella se indica el tipo de contenido a intercambiar (voz, video, etc.) y sus características (códecs, direcciones, puertos donde se espera recibirlos, velocidades de transmisión, etc.). Esto se conoce como "oferta de sesión SDP". La respuesta a esta oferta viaja, en este caso, en el cuerpo de la respuesta definitiva a la petición con el método INVITE. La misma contiene la descripción de la sesión desde el punto de vista del destinatario. Si las descripciones fueran incompatibles,^{[nota 3]} la sesión debe terminarse (mediante una petición con el método BYE).

Al terminar la sesión, que lo puede hacer cualquiera de las partes, el agente de usuario de la parte que terminó la sesión, actuando como UAC, envía hacia la otra una petición con el método BYE. Cuando lo recibe el UAS genera la respuesta con el código de estado correspondiente.

Si bien se ha descrito el caso de una sesión bipartita, el protocolo permite el establecimiento de sesiones multipartitas. También permite que un usuario esté registrado en diferentes ubicaciones pudiendo realizar la búsqueda en paralelo o secuencial entre todas ellas.

Mensajería instantánea y presencia

Un protocolo de mensajería instantánea basado en SIP, llamado SIMPLE, fue propuesto como estándar y está en desarrollo. SIMPLE puede también encargarse de la información de presencia, transmitiendo la voluntad de una persona de entablar comunicación con otras. La información de presencia es más reconocible hoy en día como el estado en los clientes de mensajería instantánea como Windows Live Messenger, AIM, Skype, Google Talk (y otros clientes XMPP).

Ejemplos de implementaciones comerciales de SIP

OpenWengo, software libre de telefonía, y Gizmo Project, en software propietario, han implementado SIP en sus clientes y servicios. Ambos programas usan SIP para aceptar las llamadas de un cliente a otro.

Otros programas de audio/videoconferencia que usan SIP:

Notas y referencias

↑ ^a ^b ^c ^d ^e Gonzalo Camarillo. "SIP Demystified". Mc Graw Hill. 2002. ISBN 0-07-137340-3
↑ Schulzrinne, Henning (mayo de 2001). The Session Initiation Protocol (SIP). clase, Columbia University.
↑ Aunque existe un desarrollo del protocolo SIP sin servidores usando estrategias de protocolos peer to peer (P2P) como los que se usan para compartir archivos (file sharing).

Notas

↑ Por ejemplo una aplicación de atención automática de llamadas.
↑ Existen situaciones en las que la descripción de sesión no se incluye en la petición INVITE sino que es generada por el usuario llamado en la respuesta al INVITE y respondida por el usuario origen en la petición ACK. Esto es utilizado en la implementación de servicios avanzados con el protocolo SIP.
↑ Es decir no coinciden los tipos de medios, o falta un tipo de medio considerado vital, entre otros casos.