Anexo II.

Descripción de la
Solución Asterisk

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 129

2. ASTERISK
2.1. Historia y Evolución de Asterisk

En este apartado se repasará la historia del software Asterisk desde sus orígenes.
Es necesario mencionar tres elementos claves en la evolución de este software cuya
unión dio origen el concepto de lo que hoy se conoce como Asterisk. Estos
elementos son Mark Spencer, Proyecto Zapata y Digium.

Digium es fundada en Huntsville, Alabama. Digium es la creadora y desarrolladora

primaria de Asterisk, el primer PBX de código abierto de la industria. A día de hoy,
Asterisk usado en conjunto con las placas de telefonía PCI, ofrece un manejo
estratégico con excelente relación costo/beneficio para el transporte de voz y datos
sobre arquitecturas TDM, conmutadas y redes Ethernet. Digium es el principal
patrocinador de Asterisk y uno de los líderes de la industria de PBX en código
abierto, siendo Mark Spencer el creador y principal soporte de Asterisk, él es hoy
admirado por el gran trabajo que realizo y por la responsabilidad que supo
acarrear.

El proyecto ZAPATA fue conducido por Jim Dixon. El es el responsable del desarrollo
del hardware de DIGIUM. Es interesante resaltar que el hardware también es
abierto y puede ser producido por cualquier empresa.

Mark Spencer, estudiante de ingeniería informática en la Universidad de Auburn

(Alabama), empezó en el mundo Linux con Slackware18 en 1994 (kernel versión
1.09). Era uno de los pocos en Auburn (Alabama) por aquellos tiempos que conocía
cualquier cosa sobre Linux. Después de una temporada con Adtran (proveedor
global de equipos de telecomunicaciones) creó su propia compañía.

Había creado en 1999 la empresa "Linux Support Services" con el objetivo de dar
soporte a usuarios de Linux. Para ello necesitaba una centralita telefónica, pero
ante la imposibilidad de adquirirla dados sus elevados precios, decidió construir una
con un PC bajo Linux, utilizando lenguaje C. Este fue el principio del fenómeno
mundialmente conocido como Asterisk®, la centralita telefónica construida por
Mark.
Acto seguido recurrió a la búsqueda de capital, encontrando el apoyo en la empresa
Adtran cuyos miembros se ofrecieron a invertir en su compañía. En ese momento,
recibía más interés en el PBX Asterisk que por sus servicios generales de
consultoría Linux.
Paralelamente a esto, Jim Dixon experimentaba con una placa Mitel89000C “ISDN
Express Development Card” y escribía un driver para el FreeBSD. La placa ocupó
poco procesamiento de un Pentium III 600Mhz, probando que si no fuese por la
limitación de I/O (La placa trataba deforma ineficiente la I/O exigiendo muchos
wait-states) podría atender de 50 a 75 canales. En base a este descubrimiento creó
nuevo diseño de tarjeta ISA que usaba el I/O de forma eficiente. Consiguió dos T1s
(48 canales) de datos transferidos sobre el bus entre memoria y el microprocesador
y el PC.

Sabiendo que se trataba de una idea revolucionaria, lo nombró proyecto ZAPATA en

honor al revolucionario Emiliano Zapata y llamó a la placa ‘Tormenta’. Escribió el
driver completo y se puso en marcha para vender la placa. Sin embargo, no tuvo la

18
Slackware Linux es la distribución Linux más antigua que tiene vigencia. Desde su primer lanzamiento
en 1993, el Proyecto Slackware Linux se ha esmerado en producir la distribución de Linux más
profesional posible. Slackware obedece a los estándares de Linux publicados.

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 130

aceptación esperada puesto que no era compatible con Linux. Resuelto a solucionar
este inconveniente, trató de solventarlo, pero comenzó a tener problemas en
desarrollar el módulo del kernel en la forma de módulos cargables. Con la
esperanza de que algún gurú de Linux le ayudara a modificarlo en un “Linux”
apropiado, lo liberó en la red. En 48 horas recibió un e-mail de un sujeto de
Alabama (Mark Spencer), que se ofreció para hacer exactamente esto.
Mark tenía algo que sería perfecto en conjunto con la placa desarrollada por Jim
Dixon, naciendo Asterisk.

En ese momento Asterisk era un concepto funcional, porque no tenía una

forma real de funcionar de forma práctica y útil. El casamiento del sistema de
telefonía Zapata y el diseño de bibliotecas de hardware/driver e interfaces
permitirían a Asterisk crecer para ser un PBX real que podría hablar con teléfonos y
líneas reales. De ello se encargarían Mark Spencer y Jim Dixon. Mark era brillante
en VoIP, redes, en la parte interna del sistema etc., y tenía un gran interés en
teléfonos y telefonía, pero tenía experiencia limitada en sistemas de telefonía y
como estos funcionaban, particularmente en el área de interfaces de hardware,
campo en el que era especialista Jim Dixon.

Su primer proyecto fue construir una tarjeta T1 Open Source. Estos ingresos les
mantenían a flote pero no recibían contribuciones de nadie y el resto tan solo
cogían sus diseños y manufacturaban tarjetas que competían con las suyas.
Posteriormente "Linux Support Services" se convertiría en el año 2002 en "Digium",
redirigiendo sus objetivos al desarrollo y soporte de Asterisk. El dinero era escaso
en Digium hasta que un día un vendedor de DeltaCom (una competitiva compañía
de comercio local) entró para venderles a Mark y a Jim una T1. Después de
entender lo que Mark y Jim habían hecho el vendedor se ofreció a ayudarles. A
partir de este punto empezaron a ver un incremento en las ventas, y acabaron el
año con beneficios. Después de grandes ingresos durante largo tiempo Mark fue
capaz de hacer crecer el negoció sin recabar mucho en los beneficios.
Cuando Mark empezó con Asterisk hizo una cosa muy inteligente. Se le requería
firmar un acuerdo a cada desarrollador que contribuía en el código para que el
copyright se asignara a Asterisk y el compromiso que no hay encumbramientos en
el código contribuido. Esto le permitió sentirse confortable con su proyecto que era
completamente open source y que su compañía podría relicenciar el código a
vendedores OEM como 3COM y NTT. Digium también ha hecho las cosas bien al
mantener la versión de la comunidad con la funcionalidad completa y no crear una
escisión entre ellos y los que los apoyan.
La primera release19 fue Asterisk 0.1 (Diciembre de 1999), y el tarball20 ocupaba
tan sólo 124.3K que una vez descompactado venían a ser unos 506 KB en 96
archivos. Para correr Asterisk necesitábamos básicamente Linux y libaudiofile.
Esta primera release fue liberada en 1999 bajo licencia GPL2 pero tenia cláusulas
adicionales que indicaban que en todos los productos derivados debía constar el
nombre de Linux Support Services, LLC o Adtran Inc., también advertían sobre
códecs cubiertos por patentes de software, y la más curiosa es que si
emprendíamos acciones legales por infringir patentes en referencia a algún
software Open Source nuestro derecho a usar o distribuir el software se terminaba
de inmediato. De todos modos estas cláusulas duraron bien poco, ya que de los
primeros cambios que se hicieron para la release 0.1.1 fue aparte de arreglar
numerosos bugs revisar la licencia que pasó a ser pura GPL.

19
En la fase de desarrollo de un software una versión candidata a definitiva o candidata para el
lanzamiento (aunque más conocida por su nombre en inglés release candidate), comprende un producto
final, preparado para publicarse como versión definitiva a menos que aparezcan errores que lo impidan.
En esta fase el producto implementa todas las funciones del diseño y se encuentra libre de cualquier
error que suponga un punto muerto en el desarrollo.
20
Archivos comprimidos que se usan en Linux y UNIX con extensión“.tar.gz” o “.tar” o “.tar.bz2″.

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 131

La primera release fue Zapata 0.1.1 (Noviembre 2001), que venía a ser muy
parecido al original liberado por Zapata Telephony en Octubre del año 2000. De
hecho no se introdujeron cambios importantes hasta la release 0.1.6 (Marzo 2002),
donde se movieron las estructuras de red para usar malloc() cuando fuera
necesario, se le añadió soporte HDLC PPP, junto con algunos arreglos multicanal en
Torisa y Zaptel. Las funcionalidades y añadidos que no podían ser incluidas en el
núcleo se fueron incorporando al paquete Addons, y también se pasó a ofrecer
paquetes de sonidos.

El lanzamiento de Asterisk 1.0 (Septiembre 2004) fue anunciado por Mark durante
la Astricon21. El tarball de Asterisk 1.0.0 pesaba unos 9 MB, y ya varias compañías
daban soporte al desarrollo de Asterisk: Pilosoft, Inc. (soporte al desarrollo ADSI),
GFS (soporte al desarrollo ALSA), Telesthetic (soporte al desarrollo SIP), Paul
Bagyenda, Digital Solutions (desarrollo inicial del driver Voicetronix), entre otros
muchos desarrolladores que contribuían como Christos Ricudis que realizó
importantes aportes al código de Asterisk. Paralelamente a Asterisk fue lanzado
Zaptel 1.0.0 (Septiembre 2004), tenía soporte para udev22 (kernel Linux 2.6),
zttool tenía como dependencia a libnewt, parte del software también necesitaba la
librería Zapata.

Un año más tarde (Noviembre 2005) se anunciaba el lanzamiento de la versión

1.0.10 de Asterisk y Zaptel. Libpri, Asterisk-addons, y Asterisk-sounds ya no
presentaban cambios, lo cual ya dejaba entrever la discontinuidad de la rama 1.0
en favor de 1.2
Y efectivamente así fue, solo Asterisk llegó a la release 1.0.12 dejando paso a
Asterisk 1.2.0 (Noviembre 2005). La nueva rama de Asterisk fue presentada
durante la conferencia IP.4.IT en Las Vegas, Nevada. Asterisk 1.2 introducía sobre
3,000 funcionalidades y mejoras sobre el rendimiento global y eficiencia en el uso
de la memoria.

Entre las principales novedades teníamos:

Mejora de las funcionalidades de voicemail

Añadido protocolo DUNDi (Distributed Universal Number Discovery)

Configuración de Asterisk más sencilla

Creación de un motor de almacenamiento de configuración en tiempo real
sobre una base de datos

Un Asterisk Dialplan más potente

Introducción de Asterisk Extension Logic, un nuevo método flexible para
configurar el dialplan

Nueva interfaz para flujos de llamada IVR dinámicos

Acceso configurable a funcionalidades de llamada generales

Mejoras en el protocolo SIP

Nuevas funcionalidades para el protocolo IAX (Inter-Asterisk eXchange)

Uso de ficheros de sonido para la música en espera nativa

Soporte CDR customizable

Mejoras en el soporte PRI

21
Conferencias de tres días de duración que tienen como finalidad expandir el conocimiento de Asterisk.
En ella participan todos los fabricantes de hardware compatible con Asterisk.

22
Gestor de dispositivos que usa el kernel Linux en su versión 2.6. Su función es controlar los ficheros
de dispositivo en /dev. Es el sucesor de devfs y de hotplug, lo que significa que maneja el directorio
/dev y todas las acciones del espacio de usuario al agregar o quitar dispositivos, incluyendo la carga de
firmwares.

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 132

En la release 1.4.0 (Septiembre 2006), Asterisk ya contaba con 250.463 líneas de
código fuente y unas cifras que se recogen a continuación:

Esfuerzo estimado de desarrollo 66,03 -

(persona/año - persona/mes) 792,30
Estimación de tiempo (años) 2,63
Estimación de número de
25,08
desarrolladores en paralelo
Coste total estimado 8.919.128 $

Tabla 14. Beneficios Asterisk 1.4

El desarrollo de Asterisk continúa imparable, donde ya tenemos cinco betas de la

release 1.6 que aportaran de nuevo un gran número de cambios y mejoras entre
ellos una muy esperada reescritura del chan_sip, mejoras para video-conferencia,
JACK…
Hace algunos años, el propietario de Zaptel le comunicó a Digium que la marca
estaba registrada por una empresa dedicada a la telefonía, por lo que Digium tuvo
que buscar un nuevo nombre para el paquete Zaptel. Este se hizo público en 2008
y era DAHDI (Digium Asterisk Hardware Device Interface). Se “renombró” todo el
paquete Zaptel y se realizaron ciertas modificaciones bastante llamativas de
manera que tendría todas las funcionalidades de la versión Zaptel 1.4 y dejaría de
darse soporte para kernels de Linux 2.4 y sistemas de gestión de dispositivos
DevFS (en favor del uDev), por lo que los drivers actuales de Zaptel a estarían
desfasados y no seguirían recibiendo actualizaciones una vez lanzada la versión
DAHDI 2.0.0.
Actualmente, cerca de 300 desarrolladores participan en el desarrollo de los
diferentes módulos y las últimas versiones que se pueden usar de Asterisk son la
1.6.0.20 y la 2.2.0 de DAHDI. A continuación se muestra un cuadro resumen de las
versiones disponibles. Todas ellas pueden ser descargadas en la página de Digium.

Versión Asterisk LibPri Zaptel DAHDI

1.6.0 1.6.0.20 1.4.10.2 n/a 2.2.0
1.4 1.4.25 1.4.10 1.4.12.1 2.2.0
1.2 1.2.31 1.2.8 1.2.27 n/a

Tabla 15. Versiones Estables Asterisk

Cuando se le pregunta a Mark sobre el futuro del hardware open source no está
convencido que funcione de la misma forma que el software. Él cita la barrera para
entrar en la producción de hardware en contra del punto mucho más bajo para
entrar en el desarrollo software.

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 133

 2.2. PROTOCOLOS DE SEÑALIZACIÓN SOPORTADOS POR
ASTERISK

La señalización en VoIP tiene un papel muy importante en la red, ya que es la

encargada de establecer, mantener, administrar y finalizar una conversación entre
dos puntos. Además de ofrecer funciones de supervisión, marcado, llamada y
retorno de tonos de progreso; también se encarga de proveer QoS en cada canal de
transmisión. En los siguientes apartados se describe alguno de los protocolos más
importantes utilizados en VoIP.

H.323

H.323 es una familia de estándares desarrollado por la ITU en 1996 con el objetivo
de ofrecer un mecanismo de transporte para servicios multimedia sobre redes que
no garantizan QoS, aunque su uso se ha extendido sobretodo al uso sobre redes IP.
Pese a que inicialmente fue definido como un protocolo de videoconferencia,
rápidamente ha ido evolucionando para cubrir todas las necesidades de la VoIP. De
hecho el protocolo VoIP generaliza los conceptos introducidos por H.323. Además
especifica aspectos basados en el sistema de señalización número 7 (SS723) para la
interconexión con la PSTN.

Se trata de una recomendación bastante cerrada donde se define los códecs a

utilizar, tanto en audio como en video, y los protocolos de transporte de la
información. De hecho fue el primer estándar en adoptar como medio de transporte
el protocolo RTP, siendo capaz de aplicar algoritmos de encriptación de la
información, evitando de esta manera añadir elementos de seguridad adicionales a
los requeridos para la conexión a Internet.

Pese a que técnicamente es un protocolo potente y maduro, el interés por parte de

los usuarios y empresas actualmente ha disminuido debido principalmente a su
complejidad y a ciertas ineficiencias detectadas en conferencias entre un número
elevado de terminales.

SIP

SIP (Session Initial Protocol) es un protocolo desarrollado por el IETF en 1999 para
el control de llamadas multimedia y la implementación de servicios telefónicos
avanzados.
SIP está basado en HTTP (HyperText Transfer Protocol) adoptando las
características más importantes de este estándar como son la sencillez de su
sintaxis y una estructura cliente/servidor basada en un modelo petición/respuesta.
Otra de las ventajas de SIP es su sistema de direccionamiento. Las direcciones SIP
tienen una estructura parecida a la de un correo electrónico dotando a sus clientes
de una alta movilidad facilitando una posible integración en comunicaciones
móviles. Cabe destacar que aunque originalmente SIP tenía como objetivo la
simplicidad, en su estado actual se ha vuelto tan complejo como H.323.

23
El sistema de señalización por canal común nº 7 es un conjunto de protocolos de señalización
telefónica empleado en la mayor parte de redes telefónicas mundiales. Su principal propósito es el
establecimiento y finalización de llamadas, si bien tiene otros usos. Entre estos se incluyen: traducción
de números, mecanismos de tarificación pre-pago y envío de mensajes cortos

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 134

El protocolo SIP, desarrollado por el IETF, es responsable de establecer las
llamadas y del resto de funciones de señalización. Cuando hablamos de señalización
en el contexto de llamadas de voz, estamos hablando de la indicación de la línea
ocupada, los tonos de llamada o que alguien ha contestado al otro lado de la línea.
SIP hace 3 cosas importantes:

Encargarse de la autentificación.

Encargarse de la calidad de una llamada telefónica.

Encargarse de las direcciones IP y puertos que se van a utilizar para enviar y
recibir las “conversaciones de voz”.

Pero el gran potencial de SIP reside en su flexibilidad ya que ofrece la posibilidad de

programar nuevos servicios no definidos por la propia recomendación. Entornos de
programación como CGI (Common Gateway Interface) o sencillos lenguajes de
programación como CPL (Call Processing Language) son alguna de las herramientas
para la implementación de servicios sin que conlleve a un peligro para la integridad
del sistema. Esta es la característica principal por la que SIP actualmente goza de
un mayor éxito que H.323.

Los clientes SIP llamados peers o user agents usan el puerto 5060 en TCP
(Transmission Control Protocol) y UDP (User Datagram Protocol) para conectar con
los servidores SIP. SIP es usado simplemente para iniciar y terminar llamadas de
voz y video. Todas las comunicaciones de voz/video van sobre RTP.

MGCP-MEGACO

Media Gateway Control Protocol (MGCP) es otro estándar de señalización para VoIP
desarrollado por la IETF. MGCP está basado en un modelo maestro/esclavo donde
el Call Agent (servidor) es el encargado de controlar al gateway. De esta forma se
consigue separar la señalización de la transmisión de la información, simplificando
la integración con el protocolo SS7.
Esta importante ventaja propició la colaboración conjunta entre el IETF y la ITU
para el desarrollo de una nueva especificación basada en MGCP que fuera
complementaria a SIP y H.323. El resultado fue MEGACO aunque la ITU se refiere a
este protocolo como H.248. En definitiva, SIP y H.323 se utiliza para la señalización
en los extremos, mientras que MEGACO es óptimo para los grandes operadores de
telefonía.

IAX

Inter-Asterisk eXchange protocol (IAX) fue desarrollado por Digium para la

comunicación entre centrales telefónicas basadas en Asterisk aunque actualmente
se ha implementado clientes que también soportan este protocolo.
El principal objetivo de IAX es minimizar el ancho de banda utilizado en la
transmisión de voz y vídeo a través de la red IP y proveer un soporte nativo para
ser transparente a los NATs (Network Address Translation). 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, generalmente el 4569.
El protocolo original ha quedado obsoleto en favor de su segunda versión conocida
como IAX2. Se caracteriza por ser robusto y simple en comparación con otros
Estructura de Asterisk

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 135

 2.3. INTERFACES

Se entiende por interfaz al circuito físico que establece la conexión entre dos
sistemas permitiendo su comunicación. Las interfaces no son universales sino que
existen diferentes estándares que establecen especificaciones técnicas concretas.

Los puertos de comunicación más comunes que se pueden encontrar en una

centralita PBX son:

FXO (Foreing eXchange Office). Conexión a extensiones de otras centralitas

o a la PSTN.

FXS (Foreing Exchange Station). Conexión a enlaces de centralitas, teléfonos
analógicos (POTS, Plain Old Telephone System) y faxes.

E&M. Conexión específica a otras centralitas.

BRI. Acceso básico RDSI (2B+D)

PRI. Acceso primario RDSI (30B + D).

Los términos FXO y FXS siempre llevan a confusión debido a que siendo conceptos
diferentes siempre van juntos.

FXS es un puerto usado por las líneas de telefonía analógica (también denominados
POTS), este puerto envía señales de timbre y tono para teléfonos analógicos. Es
decir, que emulan a una línea telefónica analógica tradicional.

FXO este puerto recibe las señales del puerto fxs. Un teléfono tienes un puerto fxo.
Este puerto no envía señales de tono o timbrado, solo recibe las señales que envía
los FXS. Funciona como terminal de línea.

Figura 51. FXS y FXO

Una central IP recibe una línea FXS en un puerto FXO para conectarse al servicio de
telefonía. En el caso de las tarjetas Digium, por ejemplo TDM400, se pueden
colocar módulos con estos tipos de puertos.

En cualquier caso, el número de interfaces dependerá del tamaño y del escenario a

implementar y se profundizará en ello en el apartado correspondiente a la solución
adoptada.

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 136

 2.4. CÓDECS
Códecs de Audio
Durante este apartado, se describirán brevemente los códecs, tanto de video como
de audio que soporta Asterisk. En el capitulo anterior se profundizó en las técnicas
de codificación así como la forma de elegir el códec más apropiado en función de
las necesidades del proyecto y las limitaciones que estos conllevan al ser usados en
Asterisk.

Los códec o codificadores de audio se utilizan para digitalizar, comprimir y codificar

la señal de audio analógica para poder ser transmitida por la red. Los códecs son
algoritmos matemáticos implementados en software encargados de convertir ondas
analógicas a información digital. Existen diversos modelos utilizados en VoIP
dependiendo del algoritmo escogido en la transmisión, la calidad de la voz, el ancho
de banda necesario y la carga computacional.

Además de la ejecución de la conversión de analógico a digital, el códec comprime

la secuencia de datos, y proporciona la cancelación del eco. La compresión de la
forma de onda representada puede permitir el ahorro del ancho de banda. Esto es
especialmente interesante en los enlaces de poca capacidad y permite tener un
mayor número de conexiones de VoIP simultáneamente.

El sistema auditivo del ser humano es capaz de captar las frecuencias

comprendidas entre 20 Hz y 20 kHz y la mayoría de códecs procesan la información
dentro de la banda de 400 Hz- 3,5 kHz para que a la hora de reconstruir la señal,
ésta siga siendo inteligible. Sin embargo, Asterisk, no soporta todos los códecs
existentes. A continuación se presenta un breve resumen de los códecs de audio
soportados por Asterisk y sus características más relevantes como son:

El Bit Rate indica la cantidad de información que se manda por segundo.

El Sampling Rate indica la frecuencia de muestreo de la señal vocal (cada
cuanto se toma una muestra de la señal analógica).

El Retardo indica cada cuántos milisegundos se envía un paquete con la
información sonora.

El MOS indica la calidad general del códec (valor de 1 a 5).

Entre los códecs anteriormente mencionados se encuentran:

G.711. El algoritmo es logarítmico y existen dos leyes:

 µ-law: Usado sobre todo en Norte América y Japón. Codifica cada 14

muestras en palabras de 8 bits
 a-law: Usado en Europa y en el resto del mundo. Codifica cada 13
muestras en palabras de 8 bits

G.723.1: Algoritmo estandarizado por la ITU-T en 1995 puede operar a 6.3

kbps o 5.3 kbps.

G.726: Estándar de la ITU-T, conocido también como ADPCM (Adaptative

Differential Pulse Code Modulation), sustituyó a G.721 en 1990. Permite
trabajar con velocidades de 16, 24, 32 y 40 kbps. Este códec proporciona
una disminución considerable del ancho de banda sin aumentar en gran
medida la carga computacional.

G.729: Se usa sobre todo en aplicaciones de Voz sobre IP por los bajos
requerimientos en ancho de banda. Opera con tasas de 8 kbps pero existen

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 137

 extensiones para tasas de 6.4 y 11.8 kbps para peor o mejor calidad de voz
respectivamente.

GSM (Global System Mobile): Estándar que opera a 13 kbps con una carga
de CPU aceptable. Inicialmente fue desarrollado para la telefonía móvil.

iLBC (Internet Low Bit rate Codec): Algoritmo complejo desarrollado por
Global IP Sound (GIPS) que ofrece una buena relación ancho de
banda/calidad de voz a cambio de una mayor carga computacional. Opera a
13.3 kbps y 15.2 kbps.

Speex: Implementa un algoritmo capaz de variar la velocidad de transmisión

dependiendo de las condiciones actuales de la red (VBR: Variable Bit Rate).
El ancho de banda puede variar desde 2.15 a 22.4 kbps.

MP3 (Moving Picture Experts Group Audio Layer 3 Enconding Standard):

Codec de audio optimizado para música y no para telefonía creado por la
ISO. Es utilizado sobre todo en los teléfonos IP para la música en espera.

En la siguiente figura se muestra un breve resumen:

Bit per Sampling Rate Retardo

Códec Bit Rate (Kb/s) Sample (kHz) (ms) MOS
G.711 64 13 8 20-30 4.1
G.723.1 5.3/6.4 13 8 37.5 3.9
G.726 16/24/32/40 13 8 20-30 3.85
G.729 8 13 8 15 3.92
GSM 13 13 8 20
ILBC 13.2/15.2 16 8 20-30
LPC10 2.4 8 22.5
2.15-24.6 (NB) 30 (NB)
SPEEX 16 8,16,32
4-44.2 (WB) 34 (WB)
8, 11.025, 12, 16,
Valores entre 8 -
MP3 Any 22.05, 24, 32, 44.1, >100ms
320
48

Tabla 16. Resumen códecs audio compatibles con Asterisk

Es importante recalcar el hecho de que el principal objetivo es aunar la eficiencia y

la calidad de la voz.

Códecs de video.

Un códec de video es un tipo de códec que permite comprimir y descomprimir video

digital. Normalmente los algoritmos de compresión empleados conllevan una
pérdida de información. El problema que se pretende acometer con los códec es
que la información de video es bastante ingente en relación a lo que un ordenador
normal es capaz de manejar. Es así como un par de segundos de video en una
resolución apenas aceptable puede ocupar un lugar respetable en un medio de
almacenamiento típico (disco duro, CD, DVD) y su manejo (copia, edición,
visualización) puede llevar fácilmente a sobrepasar las posibilidades de dicho
ordenador o llevarlo a su límite.

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 138

Asterisk soporta diferentes códecs de vídeo. A continuación se detallan estos códecs
y el ancho de banda requerido para su uso:

H.261 (entre 40 Kbits/s y 2 Mbits/s)

H.263 (desde menos de 64 Kbits/s hasta 583.9 Mbits/s sin compresión)

H.263p (Asterisk 1.4) (desde menos de 64 Kbits/s hasta 583.9 Mbits/s sin
compresión)

H.264 (Asterisk 1.4) (entre 64 Kbits/s y 960 Mbit/s)

A la hora de elegir un códec de video para usar con Asterisk, es importante conocer
que Asterisk (la versión 1.6.1 usada) por si mismo no soporta ningún tipo de
transcodificación de vídeo. Para activar el soporte de vídeo en Asterisk (sin
parchear) se debe de activar tan solo un códec de vídeo en sip.conf.

Cada nuevo estándar (o códec) es substancialmente mejor a la anterior versión,

aunque a pesar de ello la elección no es tan obvia. Debemos tener en cuenta otros
aspectos relacionados con el uso de códecs como tipos de licencias.
También pueden existir otros factores como la necesidad de interconectar con otros
sistemas de videoconferencia, la infraestructura actual, los videoteléfonos que
vamos a utilizar (como en el caso de Eyebeam y H.263p). Aunque cabe decir que la
mayoría de los sistemas de videoconferencia soportan tanto H.261 como H.263 y
H.264

La posibilidad que ofrece Asterisk con el uso de los códecs, permite multitud de
combinaciones para su uso, desde la videoconferencia, pasando por la video
vigilancia a un simple video de bienvenida dentro del servidor. Todos estos videos,
pueden estar en formatos diferentes, o que sean los elementos hardware los que
por configuración solamente soporten un tipo de códec determinado.

Puesto que en este aspecto Asterisk todavía está limitado, se podría hacer uso de
programas externos que pasen de un códec a otro, salvando así no solo la
limitación de nuestro servidor sino también el hecho de que aunque Asterisk fuese
capaz de hacer transcodificación de vídeo, el consumo de recursos sería
posiblemente desmedido.

Para solucionar este problema se usarán programas como el VLC (inicialmente

VideoLAN Client) es un reproductor y framework multimedia del proyecto
VideoLAN; es software libre distribuido bajo la licencia GPL. Soporta muchos códecs
de audio y video, así como diferentes formatos de archivos, además de DVD, VCD y
varios protocolos de streaming; también tiene la capacidad de transmitir datos
streaming a través de redes y convertir archivos multimedia en formatos distintos
al original.
Es uno de los reproductores más independientes en cuanto a plataforma se refiere,
con versiones para GNU/Linux, Microsoft Windows, Mac OS X, BeOS y BSD, entre
otros.
VLC incluye de forma nativa un gran número bibliotecas de códecs, reduciendo la
necesidad de instalar o calibrar códecs propietarios. Muchos de los códecs incluidos
en VLC son proporcionados por la biblioteca libavcodec del proyecto FFmpeg,
aunque principalmente utiliza sus propios filtros de multiplexación (muxer).

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 139