6/07/2014

El protocolo SIP

Shop all computers at the Microsoft Store! Click Here

El protocolo de Inicialización de Sección (SIP)  es un protocolo desarrollado por el grupo de trabajo MMUSIC 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 vídeo, voz, mensajería instantánea, juegos en línea y realidad virtual.

El protocolo SIP trata cada extremo de una conexión como un par (un peer) y se encarga de negociar las capacidades entre ambos extremo. Lo que hace a SIP atractivo es que es un protocolo relativamente simple, con una sintaxis similar a la de otros protocolos conocidos, como HTTP y SMTP. SIP es soportado en Asterisk a través del módulo chan_sip.so.


Historia


El 22 de febrero de 1996, Mark Handley y Eve Schooler presentaron al IETF un borrador del Protocolo de Invitación de Sección conocido ahora como SIPv1. El mismo estaba basado en trabajos anteriores de Thierry Turletti (INRIA Video conferencing 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.

Ese mismo día el Dr. 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.

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 la 2, 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 "estándar propuesto" en la RFC 2543 publicada en febrero de 1999.

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: Jonnathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Allan Johnston, Jon Peterson, Robert Sparks, Mark Handley y Eve Schooler.

SIP es un protocolo de señalización de capa de aplicación que usa el puerto bien conocido 5060 para comunicación. SIP puede ser transportado con los protocolos de capa de transporte ya sea UDP o TCP.
SIP no transporta datos entre dispositivos finales.  Al contrario es un protocolo de transporte en tiempo real (RTP) y es usado para este propósito. RTP utiliza una numeración de puertos altos, o puertos no privilegiados en Asterisk (10.000 – 20.000, por defecto).

SIP no fue el primer protocolo, y no es el único usado hoy día (existen otros como: H.323, MGCP, IAX, entre otros). La ventaja del protocolo SIP es que es ampliamente aceptado  y su flexibilidad arquitectónica.   

SIP y NAT


Probablemente el mayor obstáculo técnico de SIP es que tiene que conquistar el reto de llevar a cabo transacciones eficientemente a través de NAT. Porque SIP encapsulas la información de direccionamiento en frames de datos (o tramas), y NAT se lleva a cabo en la capa de red, la información de direccionamiento no es modificada automáticamente, y por lo tanto los flujos de datos de comunicación no tendrán la información de direccionamiento correcta necesaria para completar la conexión cuando existe un dispositivo NAT de por medio. Adicional a esto, los firewalls normalmente integrado con NAT no consideran los media stream entrantes como parte de una transacción SIP, y bloquean la conexión. Los nuevos firewalls y los controladores de sección fronteriza (SBCs) son conscientes de SIP pero todavía esto es considerado como una limitantes en este protocolo.

Seguridad en SIP


SIP usa un  sistema de demanda/repuesta para autenticar los usuarios. Un INVITE inicial es enviado al proxy con el cual el dispositivo desea comunicarse. El proxy entonces responde  con un mensaje de solicitud de autorización (407), el cual contiene un conjunto aleatorios de caracteres que es referido como un nonce. Este nonce se utiliza junto con la contraseña para generar un hash MD5, que es enviada de vuelta en el INVITE posterior. Asumiendo que el hash MD5 coincida con el que el proxy ha generado, el cliente es entonces autenticado.

Los Ataque de denegación de servicios (DoS) son probablemente los tipos de ataques más comunes en las comunicaciones VoIP.  Un ataque DoS puede ocurrir  cuando un gran volumen de solicitud de INVITE invalido son enviados para un servidor proxy en un intento de saturar el sistema. Esto ataques son relativamente simple para implementar, y sus efectos sobres los usuarios del sistema son inmediatos. SIP cuentas con varios métodos de minimizar los efectos de los ataques DoS, pero últimamente son imposibles de prevenir. SIP implementa un sistema para garantizar la seguridad,  un mecanismo de transporte encriptado (llamado Transport Layer Security o TLS) es usado para establecer la comunicación entre la persona que llama y el dominio del destinatario. Más allá de eso, la solicitud es enviada de forma segura para el dispositivo final, basado sobre la política de seguridad local de la red.  Leer más




El Protocolos IAX (Inter-Asterisk Exchange)

SIP Voice Terminal Adapter, 1 RJ-11 FXS Port, 1 RJ-45 Click Here

IAX es un protocolo abierto, lo que significa que cualquiera puede descargarlo, modificarlo o mejorarlo a su gusto. En Asterisk, IAX es implementado a través del módulo de chan_iax2.so.  Este protocolo fue desarrollado por Digium con el propósito de comunicarse con otros servidores Asterisk, y entre servidores y clientes que también utilizan el protocolo IAX. Es muy importante señalar que IAX no está en lo absoluto limitado a Asterisk.  Es un estándar abierto para que cualquiera lo use, y es apoyado por muchos otros proyectos de telecomunicaciones de código abierto, así como por varios proveedores de hardware. IAX es un protocolo de transporte (como SIP) que usa un solo puerto UDP (4569) para ambos canales de señalización y datos. 

Permite manejar una gran cantidad de códecs y un gran número streams, lo que significa que puede ser utilizado para transportar cualquier tipo de dato.

El protocolo IAX2 fue deliberadamente diseñado para trabajar detrás de dispositivos NAT. El uso de un único puerto UDP tanto para la señalización y la transmisión de datos, el tráfico de voz es transmitido in-band, hacen de IAX un protocolo casi transparente a los cortafuegos y realmente eficaz para trabajar dentro de redes internas. 

Está diseñado para darle prioridad a los paquetes de voz sobre redes IP. En esto se diferencia de  SIP, que utiliza cadena RTP out-of-band (fuera-de-banda) para entregar la información.

IAX2 soporta Trunking, donde un simple enlace permite enviar datos y señalización por múltiples canales.  Cuando se realiza Trunking, los datos de múltiples llamadas son manejados en un único conjunto de paquetes, lo que significa que un datagrama IP puede entregar información para más llamadas sin crear latencia adicional. Esto es una gran ventaja para los usuarios de VoIP, donde las cabeceras IP son un gran porcentaje del ancho de banda utilizado. Leer más


Shop Xbox at the Microsoft Store! Click Here

¿Por qué son necesarios los Protocolos VoIP?



La necesidad básica de los protocolos VoIP es la paquetización del audio para ser transportado sobre las redes basadas en los protocolos de Internet.

Los  retos para lograr esto se refieren a la manera en que los humanos se comunican. No sólo es necesario que la señal llegue esencialmente de la misma forma que se transmite, pero tiene que hacerlo en menos de 150 milisegundos. Si los paquetes se pierden o se retrasan, habrá degradación de la calidad de las comunicaciones, lo que significa que dos personas tienen dificultades para mantener una conversación telefónica.

Los protocolos de transporte que en su conjunto son llamados “Internet” no fueron originalmente diseñados con transmisión de streaming de audio en tiempo real en mente. Se espera que los nodos receptores resuelvan el problema de las pérdidas de paquetes por esperar un largo tiempo para que el paquete arribe, solicitando la retransmisión, o en algunos casos, considerando la información perdida como buena y simplemente seguir adelante. Nuestras conversaciones no se adaptan bien a la pérdida de letras o palabras, ni de ningún retraso apreciable entre transmisión y recepción.

La PSTN tradicional fue diseñada especialmente para el propósito de transmisión de voz, y es perfectamente adecuada para esta tarea desde el punto de vista técnico. Desde un punto de vista más flexible, sin embargo, sus defectos son evidentes incluso para las personas con un conocimiento muy limitado de la tecnología. VoIP mantiene la promesa de incorporar las comunicaciones de voz en todos los otros protocolos que llevamos en nuestras redes, pero debido a las exigencias especiales de una conversación de voz, se necesitan habilidades especiales para diseñar, construir y mantener estas redes.

El problema con la transmisión de voz basada en paquetes se deriva del hecho de que la forma en la que hablamos es totalmente incompatible con la forma en que IP transporta datos. Hablar y escuchar consiste en la retransmisión de una secuencia de audio, mientras que los protocolos de Internet están diseñados para dividir todo, encapsular los bits de información en miles de paquetes, y luego entregar cada paquete de cualquier manera posible para el extremo receptor. Es evidente que se requiere alguna forma de lidiar con esto.



Es por lo expuesto anteriormente que surgen los protocolos para VoIP, cuyo mecanismo para conexión implica una serie de transacciones de señalización entre los puntos finales (y entre gateway), que cargan dos flujos de audio para cada dirección de la conversación. Hay varios protocolos en existencias para manejar esto. En esta sección, vamos a hablar de los protocolos que en general son importantes para VoIP y especialmente  para Asterisk. Leer más

 

Habilitando NTP para Sincronizar la Hora del Sistema



Para CentOs


Mantener la hora exacta es esencial en el sistema Asterisk, tanto para el mantenimiento de los registros de detalles de llamadas precisos y para la sincronización con sus otros programas. Usted no querrá que las horas de las notificaciones del correo de voz presenten retraso por 10 ó 20 minutos, ya que esto puede llevar a confusión y pánico de aquellos que pudieran pensar que sus notificaciones de correo de voz se están tardando demasiado en ser entregada.

El comando ntpd se puede utilizar para asegurarse de que el tiempo en su servidor Asterisk se mantiene sincronizado con el resto del mundo:

# yum install ntp
...
Is this ok [y/N]: y          Está de acuerdo [s / N]: s
...
# ntpdate pool.ntp.org
# chkconfig ntpd on
# service ntpd start


Los valores por defecto que se envían con CentOS son suficientes para sincronizar la hora y mantener el tiempo de la máquina en sincronía con el resto del mundo.

En Ubuntu



$ sudo apt-get install ntp

El valor por defecto en Ubuntu es ejecutar un servidor de sincronización de tiempo sin tener que cambiar la hora en su propia máquina. Esto no funcionará para nuestras necesidades, por lo que tendremos que cambiar el archivo de configuración ligeramente. Debido a esto, tenemos que guiarlo a través del uso de un editor de línea de comandos. El editor nano ya está instalado sobre su máquina Ubuntu y es muy fácil de usar.

$ sudo nano /etc/ntp.conf

Utiliza las teclas de flecha para moverte a la sección que se parece a:


# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

Agregue dos nuevas líneas al final de esta sección, para que ntpd pueda sincronizar el tiempo con el mundo exterior, de manera que la sección anterior ahora debe ser similar a esta:

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict -4 127.0.0.1
restrict -6 ::1

Eso es todo lo que necesitamos cambiar, salga del editor por presionar Ctrl + X. Cuando se le pregunte si desea guardar las modificaciones, pulse Y; adicionalmente nano le preguntara por el nombre del archivo. Simplemente presiones ENTER para confirma el nombre por defecto /etc/ntp.conf.

Ahora reinicie el daemon de NTP:

$ sudo /etc/init.d/ntp restart

Con el sistema operativo instalado, está listo para instalar las dependencias necesarias para Asterisk.

Leer más