IAX

De Asterisk Wiki
Saltar a: navegación, buscar

El protocolo IAX fue diseñado para Asterisk por su mismo creador Mark Spencer (de ahí recibe sus siglas, Inter Asterisk eXchange, Intercambio entre Asterisk) para suplir múltiples desventajas que el protocolo SIP ofrecía en aquel momento, y que por su naturaleza original, sigue teniendo. Realmente IAX se refiere a IAX2, la segunda versión de este protocolo, dado que el primero fue reemplazado por este. IAX2 está descrito en profundidad en el RFC 5456.

Conceptos Básicos

En términos generales, IAX es el mejor protocolo de señalización y transporte utilizado entre cualquier máquina Asterisk, y a ser posible entre cualquier dispositivo que tenga algo que ver con una máquina que disponga de nuestro sistema. IAX fue diseñado en el año, pero hasta 2010 no aparecio su implementación en el RFC que comentábamos al principio.

Funcionamiento Esencial

Sistema de Trunking de IAX

En este sentido, a nivel de señalización IAX es muy similar a la mayoría de los protocolos de señalización no específicos y utilizados para la telefonía IP como los comentados anteriormente. A nivel OSI, puede trabajar tanto con puertos de carácter TCP como UDP, concretamente y por defecto suele trabajar con el 4569. Los mensajes se pasan entre dispositivos en formato Binario, al contrario de otros protocolos más comunes que pueden pasar estos mensajes en formato de texto plano, tampoco supone un hito en la seguridad, pero al menos ya no son tan evidentes.

IAX tiene dos mecanismos de transportar la información. División en paquetes para cada tramo del medio, incorporando una cabecera por cada paquete, o una característica especial, utilizando sus funciones especificas de "trunking", llevando todos los medios, en un solo paquete con una sola cabecera. Haciendo un análisis de esta funcionalidad, se puede observar como el tiempo de respuesta baja, pero a cambio es necesario que el ancho de banda sea amplio para poder soportar el aumento en tamaño de los paquetes. Si trabajamos con conexiones con muy poco ancho de banda, sería recomendable no utilizar esta capacidad de "trunking".

Hay que entender, que este protocolo originalmente, fue diseñado para conectar dos máquinas Asterisk entre si, de la forma más eficiente, segura y fácil de implementar en cualquier escenario posible. Hoy en día existen muy pocas implementaciones y dispositivos que soporten este protocolo, pero ciertos proveedores, y diseñadores de equipos, cada vez más empiezan a incorporar sus desarrollos basados en este protocolo. Hasta cierta medida, podrían considerarse los dispositivos "propietarios" de Asterisk, con la diferencia, que este protocolo puede ser implementado por cualquier PBX del mundo sin coste alguno, ya que es de libre disposición y acceso, algo que no ocurre al contrario, con protocolos específicos de otras centrales, como el protocolo SCCP (Skinny) de Cisco.

Por otro lado, a nivel de mensajes, los mensajes más comunes, con los que trabaja este protocolo son los siguientes:

  • NEW
  • ACCEPT
  • ACK
  • RINGING
  • ANSWER
  • MEDIA (este aporta ese aspecto especifico)
  • HANGUP
  • CALLTOKEN
  • AUTHREQ
Flujo Mensajes IAX[1]

Ventajas de IAX

La principal ventaja de IAX2 (en adelante IAX) es que tanto la señalización como los medios para comunicarse entre dos puntos, son multiplexados a través del mismo puerto.

Gracias a estas bondades, IAX si podría considerarse, al contrario de SIP en un verdadero protocolo de telefonía IP (VoIP, voz sobre IP), dado que fue diseñado originalmente para cumplir esta función.

Otra de las ventajas, es que al solo necesitar una cabecera para la señalización que cubre todos los medios, podemos reducir considerablemente el tamaño de los paquetes, y en consecuencia, la latencía (tiempo de respuesta), quedaría reducida proporcionalmente.

No debemos olvidar, que uno de los grandes problemas de protocolos como SIP y MGCP, es que al ser protocolos puros de señalización, los medios van a traves de otro protocolo independiente, RTP, esto significa, problemas sobre todo con los NAT, y muy específicamente, enormes con los NAT simétricos en los que hay que recurrir a soluciones, que ni siquiera hasta la fecha, estan 100% implementadas en nuestros sistemas Asterisk, como los servidores STUN, TURN, que ya comentamos algo más en detalle la sección SIP. Por ello, con la utilización de IAX, saltamos estos problemas ya que al ir todo a traves del mismo canal, y por el mismo puerto, es fácilmente acotable y parametrizable en nuestros NAT, y Cortafuegos.

Por último y no la menos importante, la capacidad de incorporar características de seguridad como mejoras desarrolladas para protocolo específicamente en el sistema Asterisk. No es necesario la instalación de añadidos, ni módulos específicos para conseguir este propósito. Todo a través del fichero de configuración especifico de IAX y casi recomendable prescribirlo por regla general. Soporta autenticación de tipo PKI (Public-Key Infraestructure) con claves RSA bastante apropiadas si tratamos de comunicaciones probablemente sometidas a eventuales accesos indebidos.

Problemas de IAX

Principalmente existen dos problemas conocidos derivados del protocolo IAX2.

Por un lado, hay que considerar que las primeras versiones de IAX, eran algo inseguras, y estaban excesivamente expuestas a los ataques de denegación del servicio (DDoS). Por ello las medidas más clásicamente utilizadas para mitigar este problema, era simplemente, limitar el número de llamadas máximo por cada host que conectase vía IAX a nuestra máquina. Por otro lado, con las versiones mas recientes de IAX2, surgió la idea de utilizar un Token de autentificación para garantizar un paso menos en la posibilidad de ver sufrir nuestra máquina ataques DDoS por máquinas sin autentificar.

En el caso de requerir por cualquier motivo, el acceso a visitantes (guest) sin autentificar, nuestra máquina quedaría bastante expuesta, pero las últimas revisiones del protocolo protegen aún más ante este problema. En términos generales podemos decir que ha existido demasiada fragmentación de este protocolo surgida a raíz de las diversas actualizaciones del mismo. Pero eventualmente si trabajamos con máquinas de la misma índole (principalmente hablando de máquinas Asterisk, con similares, versiones, etc), la seguridad en este sentido esta bastante mas garantizada que con otros protocolos como SIP, donde los ataques DDoS, por ejemplo, con envíos masivos de mensajes INVITE, suelen ser más comunes.

El segundo problema, surge a raíz de la extensibilidad del protocolo. Este tema esta más que discutido, ya que al ser un protocolo libre, es relativamente accesible su modificación (aun más difícil la actualización del borrador en el RFC del momento. En la actualidad cubre con creces su función, pero, el temor que en un futuro surjan nuevas necesidades, quizá relativas a nuevos medios que requieran mensajes específicos, y siempre comparativamente hablando con los protocolos genéricos SIP, MGCP, etc que se adaptan prácticamente a cualquier protocolo "Out of the Band" (fuera de la banda, que trabaja independientemente al protocolo en si). Para otro bando esto último podría incluso representar, más una inconveniencia que una ventaja pero ahí surge un poco el debate ante esta debilidad.

Parámetros de Configuración

Muy parecido al protocolo SIP que suele servir de referencia a la hora de configurar el protocolo IAX, muchos de los parámetros de configuración general son compartidos. Si sabemos configurar el fichero de configuración del otro protocolo, no tendremos mucha dificultad para configurar este.

Hay que considerar que el fichero de configuración especifico esta contenido por regla general en el directorio /etc/asterisk/ y concretamente se trata del iax.conf.

Configuración General

Dentro del contexto [general] podemos utilizar los siguientes argumentos comunes:

  • bindport: Aqui podemos especificar el puerto especifico al que escuchara nuestra máquina Asterisk para conexiones IAX (puerto UDP), por defecto el 4569.
  • srvlookup: Existe una cuestión que trataremos a continuación acerca del "emparejamiento" de cabeceras IAX con nuestros correspondientes pares dentro del fichero de configuración. En el caso que queramos (intentar) este emparejamiento, utilizando los nombres de host en vez de las direcciones IP, seria conveniente activar este parámetro (srvlookup = yes). Pero al depender de "terceros" (búsqueda por DNS SRV), resulta un tanto aleatoria la posibilidad que este parámetro llego a aportar algo verdaderamente de valor)
  • allow/disallow: Esta opción es aplicable tanto a los pares como a modo general. Serían los permisos para poder utilizar todos o determinados codecs. Por defecto se permiten todos y no se restringe ninguno (allow = all), por eso para permitir solo determinados codecs es fundamental primero, "prohibirlos" todos con la opción "disallow = all". Podemos encontrar mas información sobre Codecs
  • rtcachefriends: Si trabajamos con Asterisk Realtime para configurar IAX(tabla iaxpeers) sería un método de cachear a los pares, para no tener que estar haciendo consultas SQL constantemente.
  • context: El contexto por defecto al que enviaremos las llamadas dentro del Plan de Marcación. En este caso es default, y sería conveniente o definirlo en el fichero de configuración del Plan de Marcación para evitar sorpresas, o cambiarlo a un contexto ya definido y que tengamos controlado.
  • language: El lenguaje utilizado por defecto en el caso que utilicemos Aplicaciones para reproducir un mensaje de audio.

Los especificos:

  • encryption: Permite encriptar la información trasmitida a traves del protocolo IAX. Muy útil como medida de Seguridad para el sistema.
  • transfer: Ofrece la posibilidad de intercomunicar dos dispositivos IAX sin pasar por la máquina Asterisk

Adicionalmente algunos parámetros específicos para el sistema de Trunking:

  • trunk: Decidimos si vamos a utilizar esta funcionalidad o no (Yes o No)
  • trunkmaxsize: Con esto podemos decidir que los paquetes tengan un limite de tamaño y así poder ajustar este sistema a nuestro ancho de banda, evitando el problema que surgía por saturarlo y ser más ineficiente.
  • trunkmtu: Controlamos la Unidad Máxima de Transferencía de cada unidad de datos enviado a través de nuestra red.
  • trunkfreq: Podemos ajustar en milisegundos, la frecuencia de envío de paquetes. Ya son parámetros para un ajuste muy a medida de nuestra red y hay que tener cuidado al elegirlos dado que podríamos colapsar las comunicaciones.
  • trunktimestamps: Podemos mandar Marcas de Tiempo por cada trunk, y con ello habilitamos otra opción de IAX jitterbuffer
  • jitterbuffer: Creamos un Buffer para mejorar el Jitter de la conversación. En el caso que los dos pares utilicen la funcionalidad de trunking, es fundamental que la opción trunktimestamps este habilitada en ambos sentidos.

Todos los parámetros de seguridad relacionados a los "Call Token" y la concurrencia en llamadas, la debilidad del Protocolo IAX, podemos verlos en el apartado de Seguridad

Configuración Específica de los Pares

Volvemos a tener varios parámetros "compartidos" entre SIP e IAX, aparte algunos específicos como los que mencionamos a continuación:

  • allow/disallow: Mismo uso que en el caso general, pero específicamente para un par en concreto. Podemos encontrar más información sobre Codecs
  • callerid: Sirve para que nuestro destinatario vea un "Identificador" de llamada especifico cuando llamemos desde este dispositivo
  • context: Mismo uso que el caso general, especifico para el dispositivo en cuestión.
  • host: Aqui especificamos la dirección a la que nos conectamos si es un peer, en caso de ser un friend/user, podríamos especificar la opción "dynamic" y dejar abierta la posibilidad que cualquier dispositivo se conecte a nuestra máquina sin una IP en concreto.
  • permit/deny: Más opciones de seguridad, sirve para restringir las redes y mascaras de subred de las cuales dispositivos en las mismas puedan conectar a nuestra máquina. Un ejemplo podria ser permit = 192.168.1.0/255.255.255.0 permitiría solo conexiones de dispositivos entrantes cuya IP pertenezca a esta subred. Amplio en Seguridad.
  • mailbox: Si deseamos asociar un Buzón de Voz a un par concreto lo haremos a través de este parámetro. Por ejemplo 100@ventas asociaría el buzón numero 100 dentro del contexto ventas (esto es aplicable al fichero de configuración voicemail.conf que podremos ampliar en Buzones de Voz.
  • secret: La contraseña de autentificación en formato texto plano. Es altamente insegura por motivos evidentes. En caso de ser un proveedor, ya que contra nosotros se efectúa la autentificación no resultaría tanta inconveniencia (excepto por la inseguridad ante los accesos a nivel físico/sistema operativo)
  • md5secret: En un intento de aportar algo mas de seguridad al sistema es posible definir esta contraseña en vez de la ofrecida por "secret". El metodo de construcción es a través un MD5-Hash cuya base es la siguiente: <usuario>:<dominio>:<contraseña>. El "usuario" sería el mismo que el puesto entre corchetes como nombre del par, el "dominio" por defecto sería asterisk o el especificado en el parametro "realm" como vimos en los Parámetros Generales. Y la "contraseña" seria a voluntad. Ejemplo: 100:asterisk:1234
  • type: El tipo de par IAX, las posibilidades, "user", "peer" y "friend".
  • port: Si el dispositivo utiliza un puerto diferente al 5060 habría que especificarlo aquí.
  • qualify: Comprueba si el dispositivo es alcanzable con el mensaje OK, y devuelve otro mensaje en función de su disponibilidad la otra máquina, además mide el tiempo de respuesta en el momento del chequeo.
  • username: Una forma de redefinir el usuario de autentificación, en caso que no queramos utilizar el nombre del dispositivo que se encuentra entre corchetes como comentabamos antes. Al contrario que en SIP que este parámetro ya estaba obsoleto en favor de "defaultuser".

Algunos específicos:

  • dbsecret: Seleccionamos la ruta exacta en nuestra base de datos AstDB la que apuntan las contraseñas de los usuarios IAX.
  • auth: Tipo de Autentificación para el par en concreto, puede tomar valores como "plain", "rsa" o "md5".

Es interesante saber, que IAX solo tiene un método de marcación de tonos DTMF por tanto no existen parámetros específicos para variar este comportamiento.

Información Genérica sobre los Pares

Al igual que es posible ver en el apartado de Tipos de Pares de SIP, pero específicamente destinado a IAX, los mismos criterios se aplican para su configuración. En este sentido no hay nada especial que ampliar por la tanto la propia referencia anterior haría las veces explicativas. En este sentido, los pares se comportan de forma muy similar.

Por otro lado, con respecto al sistema de nombramiento, ocurre exactamente lo mismo, pero es menos común hablar de esto en el entorno del protocolo IAX puesto que por regla general, los Pares de tipo teléfono, o punto final de conexión (Softphones incluidos), suelen utilizar el protocolo SIP. Es cierto que cada vez más dispositivos incorporan el protocolo IAX como venimos observando a lo largo del artículo, pero curiosamente, los más populares, aun siguen siendo reticentes a incorporarlo y aún más chocante, los teléfonos presentados por Digium solo ofrecen posibilidades dentro del protocolo IAX lo que resulta un golpe en contra de la popularización de este gran protocolo.

Además también como es posible contemplar en el el protocolo SIP acerca del uso de plantillas para configurar múltiples pares de forma más genérica, también es posible, pero ocurre lo mismo, no es algo extendido dado que es muy típico ver ficheros iax.conf, con apenas muy pocos pares configurados (otras máquinas Asterisk que se entrelazan).

Acceso a Invitados

Esta parte forma realmente una sección de Seguridad, pero realmente no deja de ser una funcionalidad más del protocolo IAX

Para poder permitir el acceso a los mismos es necesario eliminar el hecho de la obligatoriedad en la solicitud del Token de Llamada puesto que no se realizaría ninguna autentificación realmente. Además como comentado en el apartado de Seguridad puede resultar verdaderamente importante limitar el parámetro maxcallnumbers_nonvalidated a límites que sepamos que nuestra máquina puede controlar, dado que esta libertad de acceso puede suponer un grave contratiempo si no esta bien controlado. Un ejemplo de configuración de un fichero IAX con posibilidades limitadas de acceso a Invitados podría ser así (en formato muy simplificado pero funcional):

Archivo: /etc/asterisk/iax.conf
[general]
maxcallnumbers_nonvalidated = 2048

[guest]
type = user
requirecalltoken = no
context = invitados


Es importante tener en cuenta, que este contexto por defecto, apuntado al contexto "default", ya esta habilitado, por tanto si no somos conscientes de esto, permitimos acceso a invitados. Simplemente poniendo el parametro requirecalltoken = yes sería una forma de limitar esta funcionalidad.

Referencias

  1. Flujo Mensajes IAX, VoipThink, IAX communication example- messages (2010)

Véase también

Enlaces Externos