Tabla de Contenidos

Señalización en telefonía IP

Por herencia histórica, la señalización en voz sobre IP sigue unos principios muy parecidos a la señalización en RTB. Las señales y las conversaciones están claramente diferenciadas. En esta sección introducimos dos protocolos de VoIP que vamos a integrar en nuestra futura PBX: SIP e IAX2.

Session Initiation Protocol (SIP)

El protocolo de señalización de inicio de sesión, del inglés Session Initiation Protocol (SIP), es una especificación para Internet para ofrecer una funcionalidad similar al SS7 pero en una red IP. El protocolo SIP, desarrollado por el IETF, es responsable de establecer las llamadas y del resto de funciones de señalización. Recuerda que, cuando hablamos de señalización en el contexto de llamadas de voz, estamos hablando de la indicación de línea ocupada, los tonos de llamada o que alguien ha contestado al otro lado de la línea.

SIP hace tres cosas importantes:

  1. Encargarse de la autentificación.
  2. Negociar la calidad1) de una llamada telefónica.
  3. Intercambiar las direcciones IP y puertos que se van utilizar para enviar y recibir las “conversaciones de voz”.

Servidores Proxy

Aunque dos dispositivos SIP (teléfonos IP) pueden comunicarse directamente, SIP normalmente hace uso de algunos elementos adicionales llamados “proxies” para facilitar el establecimiento de las llamadas. Un “proxy” opera como un representante (apoderado) que se encarga de negociar entre dos partes. Con la ayuda de un “proxy” puedes mover físicamente tu número de teléfono en Internet. Los números no están asociados a un sitio concreto sino que se pueden mover siempre y cuando notifiquemos al “proxy” de nuestra (nueva) ubicación. Como el “proxy” funciona como un intermediario es capaz de indicar a las partes dónde se encuentran los teléfonos. Este servidor intermedio en SIP aprende la posición de sus usuarios durante un proceso que se conoce como “registro”.

img440.imageshack.us_img440_7692_voip4d02fx5.jpg

Protocolos en tiempo real y el NAT

En Internet, las conversaciones que usan señalización de tipo SIP resultan en flujo constante de paquetes de pequeño tamaño entre los comunicantes. Estos paquetes de voz hacen uso de otro protocolo llamado RTP. El protocolo de transporte de tiempo real o Realtime Transport Protocol (RTP) es el encargado de llevar las conversaciones (la voz) de un lado a otro. En el RTP se define un mecanismo estándar para enviar audio y vídeo en Internet. De la misma forma que en una conversación existen dos flujos de voz, en una conversación en una red IP tenemos dos flujos de paquetes RTP.

Los Network Address Translators (NATs) son los grandes enemigos del RTP. Una red con un NAT consiste en varios ordenadores compartiendo, con el mundo exterior, una sóla dirección IP pública. Las máquinas situadas dentro de la red NAT usan direcciones “privadas”. Aunque el NAT permite conectar más fácilmente ordenadores a la red, lo hace al precio de no permitir una conexión puramente bidireccional. El efecto de un NAT en voz sobre IP es que no se pueden recibir conexiones iniciadas desde el exterior.

Existen varios problemas relacionados con NAT y VoIP. El más común de los problemas es conocido como “audio en una sola dirección” (oneway audio). Como recordarás, una conversación está compuesta por dos flujos de paquetes RTP distintos. En presencia de un NAT, sólo el flujo de dentro a fuera no es bloqueado; el flujo de fuera a dentro no tiene la misma suerte y puede atravesar el NAT. La consecuencia: el que inicia la llamada desde dentro del NAT no puede escuchar a la otra parte. Si los dos comunicantes se encuentran dentro de NATs las cosas se complican aún más, hasta el punto de que ningún flujo de audio llega a su destino final.

Por desgracia, las direcciones IP privadas y los NAT están especialmente presentes en todos los lugares de las regiones en desarrollo. Configurar una red con señalización SIP y NATs no es trivial. Esta guía incluye algunos consejos generales en la sección que describe los escenarios prácticos.

InterAsterisk eXchange (IAX)

La segunda versión del protocolo de comunicación entre Asterisks (InterAsterisk eXchange) se conoce como IAX22). IAX2 es una alternativa al protocolo de señalización SIP. IAX2 fue creado como parte del desarrollo de la PBX Asterisk. A diferencia del SIP, que usa dos flujos de datos para voz y otros dos para señalización, IAX2 usa sólo un par de flujos donde voz y datos coexisten. Esta forma de enviar tanto las conversaciones como la señalización por el mismo canal se conoce como inband, en contraste con el método que usa SIP, el outofband3).

Debido a su diseño, IAX2 es la opción más adecuada en regiones en desarrollo donde existen gran presencia de NATs. Además, IAX2 es capaz de empaquetar llamadas simultáneas en un sólo flujo de paquetes IP. Este mecanismo es conocido como “trunking” y su implementación resulta en ahorros en el consumo de ancho de banda.

El concepto de “trunking” se puede explicar con la siguiente metáfora: imagínate que necesitas mandar cinco cartas a gente que vive en otro país. Una posibilidad es usar un sobre por cada una de las cartas; la otra es usar un único sobre e incluir el nombre del destinatario final en la cabecera de cada una de las cartas. La agregación de llamadas en telefonía IP funciona de la misma forma y permite enviar múltiples cartas (llamadas) en un único sobre (paquete IP).

En resumen, el diseño de IAX2 es más adecuado para regiones en desarrollo por tres razones:

  1. Reduce el uso de ancho de banda por llamada.
  2. Está diseñado para operar en presencia de NATs (soporte nativo) y es más fácil de usar detrás de los cortafuegos.
  3. Reduce aún más el ancho de banda cuando se realizan varias llamadas simultáneas (como resultado del “trunking”)

1) Una de las grandes diferencias entre la telefonía tradicional y la IP es que la calidad de servicio de una conversación se puede negociar.
2) IAX2 es un protocolo de telefonía IP que utiliza un reducido número de bits en las cabeceras y que está diseñado para permitir la comunicación entre centralitas y clientes Asterisk. El contenido de voz en los paquetes se envía usando una cabecera de tan solo 4 octetos (32 bits). Una cabecera más compleja de 12 octetos se utiliza con los paquetes de control y en algunos paquetes especiales de voz (uno por minuto aproximadamente).
3) La idea de enviar la señalización dentro del canal de voz (inband) obliga a separar los paquetes de voz de los paquetes de señalización. Aunque este diseño requiere más gasto de procesamiento (CPU) ofrece mejores propiedades en presencia de cortafuegos y NATs.