El protocolo SIP (que significa Protocolo de Iniciación de Sesiones) nació en 1996 cuando Mark Handley y Eve Schooler presentaron el primer borrador ante la IETF de lo que sería un protocolo de comunicaciones IP que solucionaría gran parte de los inconvenientes de protocolos anteriores.

En este borrador se exponían conceptos nuevos y que posteriormente pasaría a utilizarse en todo el mundo como uno de los protocolos más utilizados en las aplicaciones de mensajería instantánea, aplicaciones CRM, ERP y por supuesto VoIP. Entre estos nuevos conceptos destaca alto tan básico como el “registro”, por el cual un usuario informaba a la red dónde podía recibir invitaciones de comunicaciones por parte de otros usuarios, lo que permitía que un usuario pudiera recibir un mensaje en su casa y si luego se trasladaba al trabajo y se “registraba”, el mensaje lo recibiera en el trabajo y no en su casa.

El protocolo SIP es un protocolo de señalización, es decir, SIP no transporta audio ni vídeo, por lo que sería incompleto decir que en una comunicación de VoIP en SIP solo interviene este protocolo que se transmite por el puerto 5060 TCP o UDP.

Entonces ¿como se puede enviar audio y vídeo por SIP?. Sencillamente, no se puede, SIP no está diseñado para esto, aunque sí que permite indicar el sistema y el puerto por el que se puede enviar un flujo de datos que encapsula la voz y el vídeo. Para este flujo de datos se utiliza otro protocolo: SDP (que significa “Session Description Protocol” en español “Protocolo de Descripción de Sesiones“) y envía los parámetros de inicialización de audio y vídeo transmitidos por streaming por varios puertos UDP altos (por encima del 1024)

La comunicación SIP se realiza entre lo que se denominan “Agentes de Usuario SIP” comúnmente conocido como “usuario SIP”, “Servidores de Registro” también conocido como “SIP Server” y “SIP Proxy” también conocido como “SIP Proxy” 😛

Usuarios SIP:
Un usuario SIP puede ser una aplicación de mensajería, un softphone, un teléfono IP, y en general cualquier dispositivo o software que sea compatible con SIP y que tenga la capacidad de “registrarse” con una cuenta SIP. Los usuarios SIP reciben una URI formada por “usuario”@”dominio” donde el campo dominio se corresponde con el Servidor SIP donde se encuentra registrado.

Servidor SIP:
Un servidor SIP es una aplicación o dispositivo que permite crear y gestionar cuentas SIP y permitir que los Usuarios SIP se “registren” almacenando la dirección IP donde deben acceder para realizar la comunicación con este usuario.

Proxy SIP:
Un Proxy SIP es una aplicación que permite que cualquier usuario SIP envíe un comando a otro usuario SIP.

Con estos tres conceptos claros, empieza la parte divertida, cuando dos usuarios SIP quieren hablar entre si, hace falta:
– Dos usuarios SIP (100@dominio y 200@dominio)
– Un servidor SIP donde se registrarán los dos usuarios
– Un proxy SIP para enviar los paquetes necesarios desde uno de los usuarios al otro para empezar a establecer una comunicación.

Una vez establecida la comunicación, el envío de los paquetes streaming de audio y vídeo se realiza únicamente y exclusivamente entre la aplicación registrada como 100@dominio y la aplicación registrada como 200@dominio, por lo que queda demostrado que SIP es un protocolo P2P tan mal visto por los medios de comunicación. 🙂
En este caso, el usuario 100@dominio también podría iniciar la comunicación introduciendo el usuario 200@direccionIP donde “direccionIP” sería la que tuviese ese usuario en ese instante. ¿pero qué ocurre cuando el usuario cambia de IP? ¿Perdemos la posibilidad de llamarle? Justamente para eso sirve el servidor SIP y el Proxy SIP.

Aprovechando estas definiciones interesantes, me gustaría aclarar algunas más relacionadas con la VoIP:

B2BUA (Back 2 Back User Agent)
El B2BUA es una aplicación para controllar llamadas entre usuarios SIP y se diferencia de un Proxy SIP en que este únicamente gestiona el estado de una llamada cuando se realiza, mientras que el B2BUA mantiene el estado de las llamadas y las mantiene para conseguir información valiosa en determinados entornos como facturación, redireccionamiento de llamadas en caso de caída de un proveedor SIP, etc.
Asterisk es mucho más que un B2BUA ya que no únicamente controla todo esto, si no que incluso puede llegar a realizar acciones que ni un Proxy SIP ni un B2BUA pueden realizar como: grabaciones de llamadas, sistemas de buzón de voz, reproducción de locuciones, ofrecer menús IVR, reproducir música en espera, y un larguísimo etc.

Media Gateway (MGW)
El Media Gateway es una aplicación o dispositivo que convierte la señalización SIP y el audio streaming, recibidos por SIP en el formato necesario para que sea transportado por otra “tecnología” como líneas analógicas, digitales, diferentes protocolos IP, etc.

Softswitch
El Softswitch es una aplicación o dispositivo que realiza las labores de un Proxy SIP y un Media Gateway.
Ejemplo de softswitch es el conocido FreeSwitch al que además le han añadido algunas opciones más típicas de centralitas.

PBX
Un PBX es una centralita basada en la red telefónica (analógica, digital o incluso móvil) que realiza las acciones que ya conocemos de toda centralita: gestionar transferencias, programar menús IVR, grabar conversaciones, etc.

Media Server
Un Media Server es un dispositivo o aplicación que permite almacenar contenido multimedia (audio, vídeo, imágenes, etc…) y que puede enviarla mediante algún tipo de protocolo sin importarle a quien.
Es un reproductor de contenido multimedia que se conecta a cualquiera de los sistemas que he mencionado con anterioridad y ofrece este contenido a uno o varios usuarios.
Tras esta breve explicación, espero que estos conceptos hayan quedado más claros y evitar utilizar una aplicación para realizar tareas más propias de otras. 🙂

3 Comentarios

  • Bravo Elio, estos son los posts que realmente merecen la pena. Aclara conceptos y lo explica de forma asequible 🙂

    Sólo un par de comentarios para complementar:

    – Cuando dices “Servidores de Registro también conocido como SIP Server” yo no lo diría así. Un servidor SIP puede ser un servidor de registro SIP u otras cosas. Creo que es más correcto dejarlo sólo en “SIP registrar” (servidor de registro SIP).

    – Así mismo en esa clasificación no hay cabida para, por ejemplo, un gateway RDSI/SIP que no se registra pero que envía llamadas a un servidor SIP (PBX, proxy…) que se aceptan por venir de su IP conocida.

    – Cuando dices “por lo que queda demostrado que SIP es un protocolo P2P” en realidad no es así, lo que es P2P es el RTP y su protocolo iniciador SDP. El flujo SIP debe pasar obligatoriamente por las rutas SIP necesarias (proxies, etc…). De hecho ahora mismo hay varios drafts sobre P2PSIP.

    – Sobre el B2BUA yo añadiría que se comporta como un UAS y un UAC. Es decir: tfnoA llama al B2BUA (Asterisk por ejemplo) y Asterisk es quien el contesta (haciendo de UAS). Y luego tal vez Asterisk inicie (como UAC) una llamada a otro tfnoB y haga un puente con el audio (si pasaba por Asterisk), pero tfnoA está hablando sólo con Asterisk y tfnoB está hablando sólo con Asterisk (a nivel SIP me refiero).

    Sin más, detallitos tontos. De verdad que felicidades por arrojar luz 😉

  • > Cuando dices “Servidores de Registro también conocido como SIP Server” yo no lo diría así. Un servidor SIP puede ser un servidor de registro SIP u otras cosas. Creo que es más correcto dejarlo sólo en “SIP registrar” (servidor de registro SIP).

    Cierto, es la forma “común” de llamarlo. 🙂

    > Así mismo en esa clasificación no hay cabida para, por ejemplo, un gateway RDSI/SIP que no se registra pero que envía llamadas a un servidor SIP (PBX, proxy…) que se aceptan por venir de su IP conocida.

    Eso no es exáctamente lo que hace un softswitch?

    > Cuando dices “por lo que queda demostrado que SIP es un protocolo P2P” en realidad no es así, lo que es P2P es el RTP y su protocolo iniciador SDP. El flujo SIP debe pasar obligatoriamente por las rutas SIP necesarias (proxies, etc…). De hecho ahora mismo hay varios drafts sobre P2PSIP.

    Totalmente de acuerdo, es la comunicación SIP+SDP la que realiza la conexión y el audio va punto-a-punto.

    > Sobre el B2BUA yo añadiría que se comporta como un UAS y un UAC. Es decir: tfnoA llama al B2BUA (Asterisk por ejemplo) y Asterisk es quien el contesta (haciendo de UAS). Y luego tal vez Asterisk inicie (como UAC) una llamada a otro tfnoB y haga un puente con el audio (si pasaba por Asterisk), pero tfnoA está hablando sólo con Asterisk y tfnoB está hablando sólo con Asterisk (a nivel SIP me refiero).

    Lección aprendida, aunque Asterisk puede hacerlo como tú dices o bien redirigir el paquete SIP de un terminal a otro, no tiene porqué iniciar la llamada, es entonces cuando se comporta como un SIP Proxy. 😀

Dejar un comentario

Archivos

© 2014 Sinologic, inc. All rights reserved.

Menú

Redes sociales