Protocolo IAX-IAX2
IAX (Inter-Asterisk eXchange protocol) es uno de los
protocolos utilizado por Asterisk. Es utilizado para
manejar conexiones VoIP entre servidores Asterisk, y
entre servidores y clientes que también utilizan protocolo
IAX. El protocolo IAX ahora se refiere generalmente
al IAX2, la segunda versión del protocolo IAX. El
protocolo original ha quedado obsoleto en favor de IAX2.
IAX2 utiliza un único puerto UDP, generalmente el 4569,
para comunicaciones entre puntos finales (terminales
VoIP) para señalización y datos. El tráfico de voz es transmitido in-band, lo que hace a IAX2 un
protocolo casi transparente a los cortafuegos (Firewall) y realmente eficaz para trabajar dentro de
redes internas. En esto se diferencia de SIP, que utiliza una cadena RTP out-of-band para
entregar la información, soporta Trunking (red), 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. El protocolo IAX2 fue creado por Mark Spencer para la señalización de VoIP en
Asterisk. El protocolo crea sesiones internas y dichas sesiones pueden utilizar cualquier códec
que pueda transmitir voz o vídeo. El IAX esencialmente provee control y transmisión de flujos
de datos multimedia sobre redes IP. IAX es extremadamente flexible y puede ser utilizado con
cualquier tipo de dato incluido vídeo.
El principal objetivo de IAX ha sido minimizar el ancho de banda utilizado en la transmisión de
voz y vídeo a través de la red IP, con particular atención al control y a las llamadas de voz y
proveyendo un soporte nativo para ser transparente a NAT. La estructura básica de IAX se
fundamenta en la multiplexación de la señalización y del flujo de datos sobre un simple
puerto UDP entre dos sistemas. IAX es un protocolo binario y está diseñado y organizado de
manera que reduce la carga en flujos de datos de voz. El ancho de banda para algunas
aplicaciones se sacrifica en favor del ancho de banda para VoIP.
El diseño de IAX se basó en muchos estándares de transmisión de datos, incluidos SIP (el cual es
el más común actualmente), MGCP y Real-time Transport Protocol. El principal objetivo de IAX
ha sido minimizar el ancho de banda utilizado en la transmisión de voz y vídeo a través de la red
IP, con particular atención al control y a las llamadas de voz y proveyendo un soporte nativo para
ser transparente a NAT. La estructura básica de IAX se fundamenta en la multiplexación de la
señalización y del flujo de datos sobre un simple puerto UDP entre dos sistemas. IAX es un
protocolo binario y está diseñado y organizado de manera que reduce la carga en flujos de datos
de voz. El ancho de banda para algunas aplicaciones se sacrifica en favor del ancho de banda
para VoIP.
1
Arquitectura IAX
Como indica su nombre fue diseñado como un protocolo de conexiones VoIP entre servidores
Asterisk, aunque hoy en día también sirve para conexiones entre clientes y servidores que
soporten el protocolo.
Los objetivos de IAX son:
Minimizar el ancho de banda usado en las transmisiones de control y multimedia de VoIP
Evitar problemas de NAT (Network Address Translation)
Soporte para transmitir planes de marcación
Entre las medidas para reducir el ancho de banda cabe destacar que IAX o IAX2 es un protocolo
binario en lugar de ser un protocolo de texto como SIP y que hace que los mensajes usen menos
ancho de banda.
Para evitar los problemas de NAT el protocolo IAX o IAX2 usa como protocolo de transporte
UDP, normalmente sobre el puerto 4569, (el IAX1 usaba el puerto 5036), y tanto la información
de señalización como los datos viajan conjuntamente (a diferencia de SIP) y por tanto lo hace
menos proclive a problemas de NAT y le permite pasar los routers y firewalls de manera más
sencilla.
Funcionamiento de IAX
Una llamada IAX puede consistir de muchos segmentos cada segmento puede ser
implementado utilizando diferentes protocolos. Si dos segmentos de la llamada utilizan
en el protocolo IAX y si el par intermedio determina que no necesita mantenerse el
camino de la llamada, puede supervisar un cambio en la ruta de tal manera que se elimina
2
a si mismo de la trayectoria La supervisión finaliza una vez que los pares de la ruta
optimizada confirman que ellos pueden comunicarse apropiadamente
Una llamada IAX o IAX2 tiene tres fases:
A) Establecimiento de la llamada
El terminal A inicia una
conexión y manda un mensaje
“new”. El terminal llamado
responde con un “accept” y el
llamante le responde con un
“Ack”. A continuación, el
terminal llamado da las señales
de “ringing” y el llamante
contesta con un “ack” para
confirmar la recepción del
mensaje. Por último, el llamado
acepta la llamada con un
“answer” y el llamante confirma
ese mensaje.
B) Flujo de datos o flujo de audio
Se mandan los frames M y F en
ambos sentidos con la
información vocal. Los frames M
son mini-frames que contienen
solo una cabecera de 4 bytes para
reducir el uso en el ancho de
banda. Los frames F son frames
completos que incluyen
información de sincronización.
Es importante volver a resaltar que en IAX este flujo utiliza el mismo protocolo UDP que
usan los mensajes de señalización evitando problemas de NAT.
C) Liberación de la llamada o desconexión
La liberación de la conexión es tan sencilla como enviar un mensaje de “hangup” y
confirmar dicho mensaje.
La señalización en IAX consiste en que los mensajes se pasan entre dispositivo en formato
binario y no en texto plano. Se asemeja a otros protocolos como SIP, los mecanismos para
transportar información son con trunking y sin trunking.
3
Los mensajes o tramas que se envían en IAX2 son binarios y por tanto cada bit o conjunto de bits
tiene un significado. Como hemos indicado anteriormente existen dos tipos de mensajes
principalmente:
A) Tramas F o Full Frames
La particularidad de las tramas o mensajes F es que deben ser respondidas explícitamente. Es
decir, cuando un usuario manda a otro una trama F (full frame) el receptor debe contestar
confirmando que ha recibido ese mensaje. Estas tramas son las únicas que deben ser respondidas
explícitamente.
B) Tramas M o Mini Frames
Las tramas M o mini frames para mandar la información con la menor información posible en la
cabecera. Estas tramas no tienen por qué ser respondidas y si alguna de ellas se pierde se descarta
sin más.
El formato binario de las tramas M o mini frames es el siguiente:
4
El significado de los campos es similar al de las tramas F o full frame. En este caso el bit F está
puesto a 0 y el sello de tiempo o Timestamp está truncado y solo tiene 16 bits para aligerar la
cabecera. Son los clientes los que deben encargarse de llevar un timestamp de 32 bits si lo desean
y para sincronizarlo mandar una trama F.
El Protocolo H.323
El Protocolo H.323 de la ITU-T (International Telecommunication Union), define la forma de
proveer sesiones de comunicación audiovisual sobre paquetes de red. A partir del año 2000 se
encuentra implementada por varias aplicaciones de Internet que funcionan en tiempo real
como Microsoft Netmeeting y Ekiga (Anteriormente conocido como GnomeMeeting, el cual
utiliza la implementación OpenH323). Es una parte de la serie de protocolos H.32x, los cuales
también dirigen las comunicaciones sobre RDSI, RTC o SS7.
H.323 es utilizado comúnmente para Voz sobre IP (VoIP, Telefonía de Internet o Telefonía IP) y
para videoconferencia basada en IP. Es un conjunto de normas (recomendación paraguas) ITU
para comunicaciones multimedia que hacen referencia a los terminales, equipos y servicios
estableciendo una señalización en redes IP. No garantiza una calidad de servicio, y en el
transporte de datos puede, o no, ser fiable; en el caso de voz o vídeo, nunca es fiable. Además, es
independiente de la topología de la red y admite pasarelas, permitiendo usar más de un canal de
cada tipo (voz, vídeo, datos) al mismo tiempo.
Arquitectura H. 323
H.323 define cuatro elementos fundamentales en
la arquitectura de red
Los terminales son puntos finales de la
red que permiten comunicaciones
bidireccionales en tiempo real. Todo
terminal debe permitir comunicaciones de
voz, mientras que los vídeos o los datos
son opcionales. También debe soportar
H.245, que es el protocolo usado para
negociar el uso de los canales y las
5
características de los datos. También serán obligatorios otros tres componentes: Q.931
para señalización de llamada, RAS para comunicaciones con un Gatekeeper, y soporte
para RTP/RTCP para la secuenciación de paquetes de audio y de vídeo. Los terminales
más habituales que pueden encontrarse son teléfonos, videoteléfonos, dispositivos IVR
(Interactive Voice Response), sistemas de buzón de voz o teléfonos software.
Las pasarelas son los elementos de la red H.323 preparados para la interoperabilidad con
otras redes. Se distinguen dos elementos en la arquitectura interna de una pasarela, El
MGC (Media Gateway Controller), es el encargado de la gestión y traducción de los
elementos de la comunicación relativos a la señalización de llamada en ambos extremos
(como H.225.0 y SS7, por ejemplo). Controla así la facción de más de alto nivel de las
comunicaciones de la pasarela. El MG (Media Gateway), que maneja y traduce los
formatos de audio, vídeo o datos sobre las distintas interfaces, controlando la facción de
más bajo nivel. La comunicación entre el MGC y los MGs se lleva a cabo mediante una
especificación separada, la H.248, también conocida como MEGACO (MEdia GAteway
COntrol), y, como resultado de la colaboración entre el IETF y la ITU-T, también
disponible en la RFC 3015. Como ejemplos de pasarelas, las pasarelas analógicas con la
PSTN, las pasarelas digitales con RDSI, o incluso pasarelas con otras redes H.323
(proxys de red). Entre otras capacidades, las pasarelas con la PSTN deberán poder
reconocer señales DTMF40 y transmitirlas por H.323.
Los Gatekeepers son los elementos más importantes de una red H.323, a pesar de que su
existencia es opcional. Actúan como punto central para todas las llamadas de su Zona, y
proporciona servicios de control de llamadas a todos los puntos finales registrados en él.
De esta forma, una Zona es el grupo de terminales, pasarelas y MCUs gestionados por un
Gatekeeper.
Los elementos de borde suponen un nivel más en la jerarquía de direccionamiento
H.323, dotando de mayor flexibilidad y potencia a la gestión de rutas. En realidad su
funcionamiento es como el de cualquier Gatekeeper, sólo que, además, guardan en su
interior la información de tablas de rutas de todos los Gatekeepers dentro de su Dominio
Administrativo, participando además de la autorización de llamada entre estos dominios.
Un Dominio Administrativo no es, en definitiva, sino un conjunto de Zonas bajo el
control de un único elemento de borde. Por lo demás, el elemento de borde comparte el
resto de funciones del Gatekeeper, existiendo, por ejemplo, la posibilidad de definir
alternate Border Elements en cada Gatekeeper.
Las MCUs (Multipoint Control Units, unidades de control multipunto) soportan la
gestión de las multiconferencias. Son elementos opcionales, pero su uso resulta una
potente capacidad para administrar y gestionar multiconferencias de forma robusta. Una
MCU se descompone en un MC (Multipoint Controller, controlador multipunto), y en
cero o varios MPs (Multipoint Processors). El MC gestiona la señalización de las
llamadas entre todos los terminales, estableciendo las capacidades para procesado de
audio y vídeo entre todos, y determinando qué flujos se establecerán en multicast.
Mientras, los MPs mezclarán, conmutarán y procesarán los flujos de datos en tiempo real.
6
Funcionamiento de H. 323
La función de señalización está basada en la recomendación H.225, que especifica el uso y
soporte de mensajes de señalización Q.931/Q932. Las llamadas son enviadas sobre TCP por el
puerto 1720. Sobre este puerto se inician los mensajes de control de llamada Q.931 entre dos
terminales para la conexión, mantenimiento y desconexión de llamadas.
Los mensajes más comunes de Q.931/Q.932 usados como mensajes de señalización H.323 son:
Setup. Es enviado para iniciar una llamada H.323 para establecer una conexión con una
entidad H.323.
Entre la información que contiene el mensaje se encuentra la dirección IP, puerto y alias del
llamante o la dirección IP y puerto del llamado.
Call Proceeding. Enviado por el Gatekeeper a un terminal advirtiendo del intento de
establecer una llamada una vez analizado el número llamado.
Alerting. Indica el inicio de la fase de generación de tono.
Connect. Indica el comienzo de la conexión.
Release Complete. Enviado por el terminal para iniciar la desconexión.
Facility. Es un mensaje de la norma Q.932 usado como petición o reconocimiento de un
servicio suplementario.
El establecimiento de llamada H.225.0 puede resultar tan sencillo como el uso de sólo dos
mensajes: Setup y Connect. El resto de los mensajes servirán principalmente para prevenir
errores por temporizadores, o para proporcionar anuncios y tonos en banda (o in-band tones), es
decir, comunicación de tonos en el mismo canal que el propio canal de comunicación de la voz,
tonos como el de llamada o el de ocupado; esto se realiza principalmente en el mensaje Progress,
mediante el Progress Indicator IE. Se muestra a continuación (figura 22) un diagrama de
establecimiento de llamada en el protocolo de señalización de llamada H.225.0:
Y, también, las comunicaciones completas de establecimiento de llamada H.225.0, junto con
algunos mensajes RAS:
7
Las especificaciones H.450 describen una serie de servicios suplementarios para H.323. Entre
éstos se incluyen los servicios de transferencia de llamada, llamada en espera, indicación de
mensaje en espera, etcétera. Todos estos servicios se transmitirán “tunelizados” en IEs que serán
transmitidos en el interior de mensajes H.225.0. El funcionamiento de H.450 se verá con más
profundidad en el capítulo 2.5.8. Se muestra a continuación el funcionamiento del servicio
suplementario de redirección simple: en la especificación H.450.2 se define cómo, tras recibir un
mensaje de Setup, un mensaje Facility puede indicar un nuevo destino para esa llamada (siempre
que se envíe antes del mensaje Connect). Puede verse en la siguiente figura.
Es reseñable que muchas de estas facilidades no se encuentran implementadas en todos los
fabricantes, y que su uso, en tales casos, puede ocasionar problemas de interoperabilidad.
En una llamada H.323 hay varias fases como se indica en el siguiente gráfico y varios protocolos
cada uno de un color.
8
Una llamada H.323 se caracteriza por las siguientes fases:
1. ESTABLECIMIENTO
En esta fase lo primero que se observa es que uno de los terminales se registra en el
gatekeeper utilizando el protocolo RAS (Registro, admisión y estado) con los mensajes ARQ y
ACF. Posteriormente utilizando el protocolo H.225 (que se utiliza para establecimiento y
liberación de la llamada) se manda un mensaje de SETUP para iniciar una llamada H.323. Entre
la información que contiene el mensaje se encuentra la dirección IP, puerto y alias del llamante o
la dirección IP y puerto del llamado.
9
El terminal llamado contesta con un CALL PROCEEDING advirtiendo del intento de establecer
una llamada. En este momento el segundo terminal tiene que registrarse con el gatekeeper
utilizando el protocolo RAS de manera similar al primer terminal, el mensaje ALERTING indica
el inicio de la fase de generación de tono. Y por último CONNECT indica el comienzo de la
conexión.
2. SEÑALIZACIÓN DE CONTROL
En esta fase se abre una negociación mediante el protocolo H.245 (control de conferencia), el
intercambio de los mensajes (petición y respuesta) entre los dos terminales establecen quién será
master y quién salve, las capacidades de los participantes y códec de audio y video a utilizar.
Como punto final de esta negociación se abre el canal de comunicación (direcciones IP, puerto).
Los principales mensajes H.245 que se utilizan en esta fase son:
• TerminalCapabilitySet (TCS). Mensaje de intercambio de capacidades soportadas por los
terminales que intervienen en una llamada.
• OpenLogicalChannel (OLC). Mensaje para abrir el canal lógico de información que
contiene información para permitir la recepción y codificación de los datos. Contiene la
información del tipo de datos que será transportados.
3. AUDIO
Los terminales inician la comunicación y el intercambio de audio (o video) mediante el protocolo
RTP/RTCP.
4. DESCONEXIÓN
En esta fase cualquiera de los participantes activos en la comunicación puede iniciar el proceso
de finalización de llamada mediante mensajes CloseLogicalChannel y EndSessionComand de
H.245. posteriormente utilizando H.225 se cierra la conexión con el mensaje RELEASE
COMPLETE, por último, se liberan los registros con el gatekeeper utilizando mensajes del
protocolo RAS.
REFERENCIAS
[1] RFC 1889. [Link], [Link], [Link], [Link]. RTP: A transport protocol for real
time protocol.
[2] ITU-T Recommendation H.323: “Packet-based Multimedia Communications Systems”, November
2000.
[3] Scott Keagy, “Integración de Redes de Voz y Datos”, Ediciones Cisco Press, 2011.
[4] Juan Antonio Martínez León, “Implantación y Estudio de Técnicas de Servicios Diferenciados en
Telefonía IP sobre Redes Ethernet”, Proyecto Fin de Carrera, octubre 2003.
[5] Jonathan Davidson, James Peters, “Fundamentos de Voz sobre IP “, Ediciones Cisco Press, 2001.
10
