El protocolo SIP (Session Initiation Protocol) juega un papel fundamental en el proceso de establecimiento y finalización de las comunicaciones de VoIP. La arquitectura del protocolo SIP se describe en este otro artículo titulado Protocolo SIP de VoIP. Como complemento de aquél contenido se detallan a continuación diversos ejemplos prácticos del uso de SIP. Se explora paso a paso los mensajes y mecanismos que dan vida a las conversaciones, desde el momento en que se marca un número hasta que se despide la llamada.

SIP se ha convertido en el estándar de la industria para las comunicaciones VoIP debido a su simplicidad, flexibilidad y escalabilidad. Su naturaleza basada en texto lo hace fácil de implementar y comprender, mientras que su capacidad para manejar un gran volumen de llamadas simultáneas lo convierte en una opción ideal para entornos empresariales y de centros de llamadas.

La comunicación en SIP se basa en un intercambio de mensajes entre los dispositivos que participan en la llamada. Estos mensajes, escritos en un lenguaje formalizado, contienen información crucial que permiten iniciar la llamada, localizar al destinatario, establecer la conversación y darla por terminada.

Como sabemos, una vez que SIP da por establecida la conexión, la información digitalizada de la voz o el video se intercambian entre los participantes mediante protocolos como RTP (Real-time Transport Protocol).

SIP no se limita a las llamadas de voz y video simples. Este poderoso protocolo también admite funciones avanzadas como transferencia de llamadas, conferencias o mensajería instantánea, lo que lo convierte en una plataforma versátil para desarrollar soluciones de comunicación completas y modernas.

Cómo se produce una comunicación terminal a terminal

Bueno, ha llegado la hora de juntar todas las piezas anteriores para ver cómo se lleva a cabo el proceso de señalización para establecer una comunicación utilizando el protocolo SIP. Para empezar, pongamos el caso de una comunicación directa terminal a terminal, sin que intervengan servidores intermedios. En este caso, el proceso es bastante simple, y se compone de los siguientes pasos:

El terminal llamante le envía al llamado un mensaje de solicitud INVITE para invitarle a participar en una sesión (una llamada). En este mensaje se incluyen los parámetros propuestos para la comunicación.
Aunque existen distintas posibilidades de respuesta, dependiendo de las circunstancias, lo habitual es que el terminal llamado haga sonar el timbre para avisar a su usuario y le envíe al terminal llamante un mensaje de respuesta (código 180) para hacerle saber que está procediendo con la llamada.
Cuando el usuario llamado contesta, su terminal le envía al llamante un mensaje de respuesta OK (código 200).
Por último, el terminal llamante acepta la comunicación enviando un mensaje de solicitud ACK.
A continuación se pasa al intercambio de información multimedia (audio, vídeo o datos) utilizando RTP/RTCP.
Cuando cuelga una de las partes, su terminal envía un mensaje de solicitud BYE al otro extremo.
El terminal que recibe el mensaje BYE responde con mensaje OK (código 200) para confirmar que entiende que la comunicación ha concluido. En este punto, la llamada está terminada.

La invitación

Para escenificar este proceso con un ejemplo, supongamos que el usuario Juan (diaz@sistemas.talcual.com) quiere comunicarse con Luis (15Hgomez@finanzas.talcual. com). El mensaje de invitación sería el siguiente:

INVITE sip:gomez@finanzas.talcual.com SIP/2.0
Via: SIP/2.0/UDP sistemas.talcual.com; branch=h3zG4aJ321
Max-Forwards: 70
From: Juan<sip:diaz@sistemas.talcual.com>;tag=44551
Contact: sip:diaz@sistemas.talcual.com
To: Luis<sip:gomez@finanzas.talcual.com>
Call-ID: 16H123456@sistemas.talcual.com
CSeq: 1 INVITE
Subject: Gastos
Content-Length: 218
Content-type: application/sdp
Content-Disposition: session

v=0
o=diaz 123456 001 IN IP4 sistemas.talcual.com
s=
c=IN IP4 sistemas.talcual.com
t=0 0
m=audio 4444 RTP/AVP 2
a=rtpmap 2 G726-32/8000
m=audio 4666 RTP/AVP 4
a=rtpmap 4 G723/8000
m=audio 4888 RTP/AVP 15
a=rtpmap 15 G728/8000

La primera línea es una línea de solicitud, a la que le siguen distintas líneas con los campos de cabecera. La línea en blanco separa la cabecera del cuerpo del mensaje, donde se relacionan los campos SDP que inician la negociación de los parámetros de la comunicación.

En este ejemplo, el equipo de Juan le está comunicando al de Luis que entiende los codecs G726-32, G723 y G728. A cada uno de ellos le asigna un número de puerto distinto (número de puerto propio al que el otro extremo tendría que dirigir la comunicación. En este ejemplo: 4444, 4666 y 4888 respectivamente), lo que le permitiría establecer más de una comunicación de audio simultánea. No obstante, si sólo se va a establecer una comunicación, podría especificarse el mismo puerto para todos ellos de la siguiente forma:

m=audio 4444 RTP/AVP 2 4 15
a=rtpmap 2 G726-32/8000
a=rtpmap 4 G723/8000
a=rtpmap 15 G728/8000

Negociar los parámetros y establecer la comunicación

En primer lugar, el terminal de Luis responde que está procediendo a avisar a su usuario con el siguiente mensaje:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP sistemas.talcual.com; branch=h3zG4aJ321
From:Juan<sip:diaz@sistemas.talcual.com>;tag=44551
To:Luis<sip:gomez@finanzas.talcual.com>;tag=11222
Contact: sip:gomez@finanzas.talcual.com
Call-ID :123456@sistemas.talcual.com
cSeq: 1 INVITE
Content-Length: 0

Una vez que Luis descuelga, su terminal enviará un mensaje de aceptación donde incluye los parámetros que acepta. En el ejemplo vamos a suponer que su terminal sólo entiende el codec G.728. Para cada codec no aceptado se especifica el número de puerto 0, mientras que para los codecs aceptados se facilita un número distinto de cero (6666 en este ejemplo). A partir de este momento, cada parte conoce el codec que se va a emplear y el número de puerto del terminal distante al que tiene que enviar la información multimedia:

SIP/2.0 200 OK
Via: SIP/2.0/UDP sistemas.talcual.com; branch=h3zG4aJ321
From:Juan<sip:diaz@sistemas.talcual.com>;tag=44551
To:Luis<sip:gomez@finanzas.talcual.com>;tag=11222
Contact:sip:gomez@finanzas.talcual.com
Call-ID:123456@sistemas.talcual.com
cSeq:1 INVITE
Subject:Gastos
Content-Length:163
Content-Type:application/sdp
Content-Disposition:session

v=0
o=gomez 45678 001 IN IP4 finanzas.talcual.com
s=
c=IN IP4 finanzas.talcual.com
t=0 0
m=audio 0 RTP/AVP 2
m=audio 0 RTP/AVP 4
m=audio 6666 RTP/AVP 15
a=rtpmap 15 G728/8000

Por último, el terminal de Juan acepta la comunicación dando paso al intercambio de información multimedia. El mensaje de aceptación sería el siguiente:

ACK sip:luis@finanzas.talcual.com SIP/2.0
Via: SIP/2.0/UDP sistemas.talcual.com; branch=h3zG4aJ321
Max-Forwards:70
From:Juan<sip:diaz@sistemas.talcual.com>;tag=44551
To: Luis<sip:gomez@finanzas.talcual.com>;tag=11222
Call-ID :123456@sistemas.talcual.com
cSeq: 1 ACK
Content-Length:0

Si el terminal de Luis aceptara más de un codec y no se decidiera por ninguno de ellos en particular, los incluiría en su respuesta asignándole un número de puerto distinto de cero. En este caso, el terminal de Juan decidiría el codec a utilizar generando un nuevo mensaje INVITE en el que incluirá sólo el codec elegido.

Si por el contrario, el terminal de Luis no pudiera aceptar ninguno de los codecs proporcionados por Juan, la respuesta incluiría un código de estado 488 (No aceptable) o 606 (No aceptable). Adicionalmente, esta respuesta podría incluir en su cabecera un campo de respuesta Warning con el código 304 (tipo de codec no disponible) o 305 (tipo de codec incompatible). En este caso, el llamante podría decidirse por enviar otro INVITE que incluya otros codecs distintos o informar a su usuario de que no es posible la comunicación.

Terminar la comunicación

Si Juan termina la llamada, su terminal enviará un mensaje BYE como el siguiente:

BYE sip:luis@finanzas.talcual.com SIP/2.0
Via:SIP/2.0/UDP sistemas.talcual.com; branch=h3zG4aJ321
Max-Forwards:70
From:Juan<sip:diaz@sistemas.talcual.com>;tag=44551
To:Luis<sip:gomez@finanzas.talcual.com>;tag=11222
Call-ID:123456@sistemas.talcual.com
cSeq:2 BYE
Content-Length:0

A lo que el terminal de Luis respondería como sigue:

Cómo se produce una comunicación cuando intervienen servidores

Veamos ahora un ejemplo en el que intervienen servidores intermedios. Como en el ejemplo anterior, el usuario llamante, Juan, desea invitar a Luis a una comunicación. Al enviar esta invitación, el mensaje llega al servidor proxy del dominio de Luis. El proxy acepta este mensaje de invitación y contacta con el servidor de registro para conocer cuál es la localización exacta de Luis. El servidor de registro le informa al proxy de la dirección de Luis en este momento (la que previamente Luis había registrado). El proxy le envía al terminal de Luis una invitación, este terminal le avisa al usuario, quien descuelga. El terminal de Luis le envía una respuesta de aceptación al proxy, quien se lo retransmite al terminal de Juan. El terminal de Juan confirma la comunicación al proxy y éste se la retransmite al terminal de Luis, dando comienzo al intercambio de información multimedia.

Proceso de llamada con servidor proxy y de registro

En el caso en el que, en lugar del proxy, se tuviera un servidor de redireccionamiento, este servidor averiguaría la dirección exacta de Luis y le devolvería al terminal de Juan una respuesta de redirección (clase 300) indicándole esta dirección. El terminal de Juan aceptaría este mensaje e iniciaría una comunicación directa con el terminal de Luis.

Mejoras realizadas a SIP

La recomendación que define SIP, RFC2543, se publicó en marzo de 1999. Desde entonces, se ha ido implementando en distintos entornos y desarrollando sus aplicaciones. En muchas ocasiones se ha visto que, con pequeñas mejoras, se podría aumentar considerablemente el potencial de SIP. Todas estas mejoras están siendo estudiadas por el IETF, pero, hasta la fecha, no se ha publicado una nueva versión de SIP, aunque sí se dispone de recomendaciones independientes que recogen estas extensiones del protocolo.

Proceso de llamada con servidor de redireccionamiento y de registro

Algunas de estas mejoras han sido las siguientes:

El método INFO. Este método se detalla en la RFC2976 y resuelve la necesidad del intercambio de información durante la comunicación. Por ejemplo, esto es útil para poder transmitir los tonos multifrecuencia de los dígitos telefónicos de extremo a extremo.
Notificación de eventos. Algunas aplicaciones que utilizan SIP necesitan que sus usuarios puedan comunicar determinados eventos a la otra parte. Este es el caso, por ejemplo, de la mensajería instantánea o de un servicio de bolsa online. Esta necesidad se ha resuelto con la RFC3265. Esta recomendación añade dos nuevos métodos SIP: SUBSCRIBE (suscribir) y NOTIFY (notificar). El primero de ellos le permite a un usuario indicar los eventos de los que desea ser avisado y el segundo permite su notificación.
Mensajería instantánea. El IETF ha establecido un grupo de trabajo (conocido como SIMPLE) especialmente dedicado a desarrollar las habilidades de SIP para su uso en aplicaciones de mensajería instantánea. La mensajería instantánea supone el intercambio de contenido en tiempo real entre los participantes. Aunque, generalmente, el contenido son mensajes cortos de texto, también se pueden intercambiar imágenes u otros datos binarios. Para dar respuesta a estas necesidades, SIMPLE ha propuesto añadir a SIP el método MESSAGE (mensaje). En este caso, el usuario A que quisiera enviar un mensaje instantáneo a un usuario B, enviaría un mensaje MESSAGE con el texto incluido en el cuerpo del mensaje. El terminal B respondería con un mensaje de aceptación (código 200). Si posteriormente el usuario B quisiera enviarle un texto de respuesta al A, le enviaría un nuevo mensaje MESSAGE independiente.
El método REFER (referencia). Este método se utiliza para que un usuario pueda indicarle a otro que contacte con un tercero. La aplicación más evidente de este método es la transferencia de llamada. Por ejemplo, durante una comunicación entre Juan y Luis, este último se da cuenta de que con quien necesita hablar Juan es con Pedro, por lo que procede a transferirle la llamada, poniendo en comunicación a Juan con Pedro. En este caso, el terminal de Luis le envía un mensaje REFER al de Juan donde le incluye el campo de cabecera Refer-to (contactar con) con la dirección de Pedro. El terminal de Juan acepta el mensaje REFER de Luis con el código de respuesta 202 (aceptación, este código de estado no está definido en la versión original de SIP). Posteriormente, una vez establecida la comunicación con Pedro, le enviará un mensaje NOTIFY al terminal de Luis para indicarle que la transferencia se ha realizado con éxito. El terminal de Luis aceptará esta notificación con un código de respuesta 200. El método REFER también incluye el campo de cabecera Referred-by (referido por), que puede ser utilizado opcionalmente para informar sobre el usuario que realiza la transferencia.
Confiabilidad de las respuestas provisionales. Existen mensajes provisionales de respuesta, como 180 (ringing) o 183 (session progress), que el terminal que los recibe no tiene que confirmar su recepción. Como estos mensajes se envían en UDP, podría ocurrir que nunca llegaran a su destino, produciendo que, bajo ciertas circunstancias, el establecimiento de la comunicación quedase en un punto muerto. Para resolver este problema, el IETF ha creado la recomendación RFC3262 donde se definen mensajes de confirmación de las respuestas provisionales. En este caso se incluyen dos nuevas cabeceras: RACK (response ACK, ‘Aceptación de respuesta’) y RSEQ (Response sequence, ‘Secuencia de respuesta’). La primera es un campo a incluir en la cabecera de los mensajes de solicitud y la segunda en la cabecera de los mensajes de respuesta. También se define la option tag 100rel para ser utilizada en el campo supported de la cabecera. Por último, también se define el método PRACK (Provisional Response ACK, ‘Aceptación de respuesta provisional’).
El método UPDATE. Este método se ha pensado para poder cambiar los parámetros de una comunicación durante la misma. Para ello, durante el transcurso de la sesión se envía un mensaje de solicitud UPDATE que contiene una oferta con los nuevos parámetros de sesión. La otra parte puede o no aceptar dichos parámetros.

Ejemplo de mensajería instantánea con SIP

Más información sobre VoIP

En este artículo se han puesto ejemplos prácticos de cómo se lleva a cabo el establecimiento de la comunicación con SIP. 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:

VoIP. La telefonía de Internet (Libro web)
Protocolo SIP de VoIP
Cómo funciona la telefonía IP o VoIP

REF: VoIP PG148

Ejemplos prácticos del uso de SIP