Muchas veces hablamos de menajería y presencia, y nos quedamos en la parte de presencia. Supongo que para muchos mensajería es el SIP MESSAGE. Pues no.
SIP MESSAGE puede estar bien para intercambiar pequeños fragmentos de datos sin demasiado contexto, como un SMS en los móviles. Recordemos que a día de hoy lo que más se utiliza es SIP sobre UDP, por lo que sufrimos los problemas inherentes a este entorno:
- Falta de seguridad, los mensajes viajan en claro.
- Fragmentación. Si intentamos mandar un mensaje demasiado grande, y es fraccionado por nuestro router hay muchas posibilidades de que el otro extremo no se capaz de reconstruirlo.
Ámbos puntos anteriores pueden ser solventados utilizando SIP sobre TCP, pero aún así nos faltaría solucionar el que para mi es el problema más importante: la falta de contexto. Cada SIP MESSAGE es una transacción SIP, pero no hay ningún mecanismo que los agrupe de manera que lo que percibamos sea una conversación.
MSRP (Message Session Relay Protocol), RFC4975 viene a solucionar precisamente lo que indico arriba. MSRP define un mecanismo mediante el cual se utiliza SIP para establecer una sesión entre 2 usuarios (mediante INVITE, como una llamada) y proporcionar un canal de comunicación TCP/TLS para enviar mensajes relacionados. Relacionados, esa es la clave. La sesión MSRP dura como máximo lo que dura la sesión SIP, por lo que ya tenemos el concepto de conversación.
Para establecer el canal de comunicación TCP/TLS se utiliza el modelo offer/answer del protocolo SDP (RFC4566), un viejo conocido. Veamos como es el SDP de un INVITE que nos ofrece MSRP:
v=0
o=- 3504981162 3504981162 IN IP4 192.168.99.53
s=sipsimple 0.16.5
c=IN IP4 192.168.99.53
t=0 0
m=message 2855 TCP/TLS/MSRP *
a=path:msrps://192.168.99.53:2855/89861a3e01adca494db7;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
En el caso de MSRP, como se puede observar, la IP y el puerto de encuentran duplicadas: en las líneas c/m y en el atributo path. MSRP define que las líneas c/m han de ser ignoradas yque la información significativa sobre la conexión se encuentra en el atributo path. Analicemos un poco el atributo path:
a=path:msrps://192.168.99.53:2855/89861a3e01adca494db7;tcp
En la línea m se había definido TLS como transporte, por tanto utilizamos una dirección msrps://, si fuera TCP utilizaríamos msrp://. A continuación tenemos la dirección IP puerto desde los que se realizará la conexión hacia el otro extremo. Para finalizar tenemos el identificador de sesión, y el transporte.
Veamos como se establecería una sesión de MSRP:
Todo bien, ¿no? Pues no. Todavía tenemos un problema que solucionar: el NAT. ¿Qué pasa si Bob está detrás de NAT? Obviamente no podremos atravesar su NAT para establecer una sesión MSRP. Por suerte, el RFC4976 define una extensión al protocolo MSRP para utilizar relays en el camino y poder evitar los problemas de NAT.
El funcionamiento es sencillo: un usuario que se encuentre detrás de NAT iniciará una conexión saliente hacia un servidor que haga de relay cuando reciba un INVITE. El servidor reservará un puerto y un identificador de sesión que devolverá al usuario. Ahora el usuario utilizará estos datos al construir su respuesta, por lo que el llamante no se conectará realmente al usuario, sino al relay, y el relay al usuario. Veamos que pinta tendrá la respuesta:
v=0
o=- 3504982347 3504982348 IN IP4 192.168.99.53
s=sipsimple 0.16.5
c=IN IP4 192.168.99.53
t=0 0
m=message 54005 TCP/TLS/MSRP *
a=path:msrps://node03.dns-hosting.info:2855/PaFIw7KZEhgoC6Cc5lPunTEyOTU5OTMzNTkuMjI5OjYyLjEzMS42LjU1;tcp msrps://192.168.99.53:54005/b3bda736f12bbd94e0c9;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
Como se puede observar, el atributo path tiene 2 direcciones en este caso. La primera (de izquierda a derecha) define la conexión con el servidor relay, y la de más a la derecha la conexión del relay con el receptor. Hay 2 identificadores de sesión, el del servidor y el del cliente. Cuando el llamante inicie una conexión TCP lo hará contra el servidor, que al estar en una IP pública recibirá sin problema, y luego encaminará todos los mensajes hacia el otro usuario.
Veamos como queda ahora la secuencia para establecer una sesión MSRP:
Lo mejor de todo es que esto existe y se puede probar hoy y ahora, en el MundoReal(TM):
Creo que vale por hoy, dejamos el soporte de transferencia de ficheros a través de MSRP para otro día 
. Dejo la importancia de CPIM para un futuro post.
