Archivo de la etiqueta: MSRP

Utiliza tu propio dominio con el servicio SIP2SIP.info

Hoy os quiero hablar de un nuevo servicio que hemos lanzado hace poco en AG Projects: la posibilidad de utilizar todos los servicios que ofrece SIP2SIP.info con tu propio dominio.

SIP2SIP es un servicio gratuito que provee la infraestrucutra necesaria con soporte para SIP, MSRP (chat, transferencia de ficheros), NAT traversal (ICE), presencia SIMPLE (incluído XCAP) y multiconferencias de audio y chat. Utiliza la infraestructura SIPThor que desplegamos en nuestros clientes y que nos permite escalar el serivicio de manera horizontal.

Pues bien, ahora podéis disfrutar de todos estos servicios bajo vuestro propio dominio de manera gratuita.

Si tenéis vuestro propio dominio y con 5 cuentas (es el límite) os es suficiente, éste servicio os podría resultar interesante ya que así podéis decir a todo el mundo que os llame a vuestro correo electrónico, como venimos recomendando desde hace mucho tiempo.

Para ello basta con seguir unos sencillos pasos. En éste ejemplo voy a delegar la zona DNS saghul.net a la infraestructura de SIPThor. La razón es que GoDaddy (mi DNS registrar) no me permite crear registros DNS de tipo NAPTR (y eso que estamos en 2012…).

En caso de que ya tengáis vuestro propio servidor DNS solo tenéis que crear los registros correspondientes que vienen detallados aquí y saltar al paso 4.

 

1. Crear una cuenta de usuario

Para ello nos dirigimos aquí, y una vez nos hayamos registrado y hecho login llegaremos a esta ventana:

 

 

2. Crear la zona DNS

Rellenamos nuestro dominio y hacemos click en add.

 

3. Crear los registros DNS adecuados

Para hacer esta operación lo más sencilla posible hemos creado un template con todos los registros necesarios, basta con seleccionar “SIP2SIP infrastructure” en el campo type al crear los registros DNS.

 

 

4. Crear el dominio SIP

En la pestaña SIP, añadimos nuestro dominio.

 

5. Crear cuentas SIP (hasta 5)

Seleccionando la opción SIP accounts podemos crear hasta 5 cuentas SIP.

 

6. Molar!

Listo, ya hemos creado una cuenta SIP en nuestro propio dominio, con el servicio SIP2SIP. Al hacer click sobre la cuenta se abre una nueva ventana donde es posible configurar distintos aspectos de la misma.

 

¡Eso es todo! Ya podéis empezar a llamar por SIP y utilizar MSRP sin necesidad de instalar ningún tipo de servidor, espero que os guste 🙂

PD: La cuenta que he creado, sip:s@saghul.net es real, pero solo contesto si es un chat con MSRP 😉

¿Qué podría traer de nuevo Asterisk 12?

La semana pasada tuvo lugar la conferencia anual de usuarios de Asterisk, AstriCon, a la que no tuve la ocasión de ir 🙁 pero un par de días antes se celebró el AstriDevCon, orientada a desarrolladores.

Afortunadamente se podía participar en el AstriDevCon (en mayor o menor medida) de manera remota: había streaming del audio, se podía conectar vía SIP (o IAX2) y el canal de IRC #astridevcon se utilizó como canal adicional.

Hoy Matt Jordan ha publicado un documento con los temas que se discutieron, que podéis consultar aquí.

De todos los puntos que se cometan, me gustaría hacer hincapié en un par de ellos:

  • Desarrollo de un nuevo chan_sip
  • Soporte de MSRP

El mero hecho de que esos los elementos estuvieran sobre la mesa me anima a pensar que tal vez el año que viene tengamos un Asterisk mucho más moderno, y menos PBX, como ya comentaba Elio. Estuve un rato conectado al stream de audio, y parecía bastante evidente que un nuevo chan_sip es algo necesario:

Afortunadamente todo el mundo parecía de acuerdo. La idea en principio sería desarrollar el nuevo chan_sip en paralelo y en un momento dado eliminar completamente el actual. Suena a plan. Ya que el difunto Asterisk-SCF utilizaba PJSIP como stack SIP, es de esperar que sea la opción final, aunque otras opciones como Sofia no están descartadas.

Si unimos los recientes esfuerzos por hacer Asterisk “WebRTC enabled” a un nuevo chan_sip y a un posible soporte de MSRP, nos encontraríamos con algo que parece que evoluciona en la dirección correcta. Aunque no olvidemos que su arquitectura es la misma, así que ya veremos 🙂

 

free(SylkServer);

Me alegra mucho poder escribir hoy este post. Hace algun tiempo que publicamos en Twitter que SylkServer sería lanzado pronto. Pues ese día es hoy.

SylkServer empezó como una evolución del anterior switch MSRPSIP-chatserver. El chatserver estaba desarrollado con el API de una versión muy antigua de SIPSIMPLE, por lo que era necesario reescribir gran parte de su código. La tarea resultó más sencilla de lo esperado ya que la versión actul de SIPSIMPLE proporciona una API de mucho más alto nivel que permite una interacción sencilla con sesiones SIP con distintos tipos de streams como MSRP o RTP.

Una vez teníamos el nuevo chatserver pensamos en añadir soporte para otros timos de media, así que añadimos soporte para audio. De esta manera tenemos una conferencia que se lleva a cabo en 2 planos: audio y texto. Pero no todo el mundo tiene un cliente SIP con soporte para MSRP así que añadimos también soporte para SIP MESSAGE. Al ser un servidor de conferencias, los mensajes tienen que ser enviados ‘de parte de los usuaris’, por lo que CPIM es imprescindible. Cual fue mi sorpresa al comprobar que ningún softphone que probé lo soportaba :-(. Dejo la importancia de CPIM para un futuro post.

Una vez teníamos audio y chat nos faltaba algo muy importante: la lista de participantes. Afortunadamente tenemos una manera estándar de hacerlo: el evento conference (RFC4575). Al suscribirnos al evento conference, el servidor nos enviará un NOTIFY con un XML describiendo la sala de conferencias, incluyendo la lista de participantes. Blink se suscribe automágicamente a éste evento (cuando recibe un 200 OK del servidor con el parámetro isfocus en la cabecera Contact, para ser más exactos) y nos presentará la lista de participantes de la siguiente manera:

Finalmente, dotamos al servidor de una arquitectura de plugins de manera que se puedan desarrollar distintas aplicaciones. De momento hemos implementado ‘conference’ y tenemos algunas en el tintero, stay tuned!

SylkServer es Software Libre (GPLv3), podéis instalaros un server propio o utilizar el de testing que tenemos funcionando.

Toda la información así como las instrucciones las tenéis disponibles en la web: http://sylkserver.com/

Mensajería en SIP con MSRP

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 🙂